PSBT workflow and traits about bdk HOT 3 CLOSED

First of all, congrats for having opened issue #100! 🎉

Now on a more serious note.. I only gave a quick read to your PR, so take this more as a few general tips, but not as a proper review:

• I agree with what you said about the PsbtWallet trait not being "flexible" enough. On the other end, I think it's pretty much impossible to imagine every possible use-case a real wallet might have, especially in a library like rust-bitcoin which tries to be even more low level than BDK. My suggestion there would be to define a type in the trait called something like "Options", so that whenever the trait is implemented it is possible to define what options the wallet needs, and then take Self::Options in create_transaction. For instance, if BDK were to use it in the future, it would do so by setting that "Options" to TxBuilder<Cs: CoinSelectionAlgorithm>. Other, simpler, wallets could just set it to a Vec<(Script, u64)> for instance.

• Yeah I think it's pretty much mandatory to support signing both single inputs and full transactions: while I would prefer to always be able to sign single inputs (to allow, for instance, the mixing of input types in a single transaction) some existing software doesn't allow you to do so. One place where I encountered this was while working on neerg, since Green's backend takes the entire transaction and tries to sign every input. Moreover, not only it needs to sign the whole transaction at once, but it also checks for the presence of the other signatures, and it refuses to sign if they are not there. This lead me to add a SignerOrder type that is used to define in which order the signers should be polled in case there are more than one of them.

• The way I see it, I don't think "signers developers" (like HW manufacturers) should really care about PSBT software: I would rather see them adopt a single piece of software like HWI which exposes a generalized interface for every HW. Then, on top of it we can build PSBT software that interfaces with HWI. I believe what we have here in BDK covers pretty much all of the "quirks" any signer could have, but it requires having some kind of "state" that keeps track of which signer has already signed, which kinda sucks. I guess the options for rust-bitcoin are either defining one trait for the "signer", and then a "container" struct which is also a "signer" and internally polls the individual signers in the right order (let's call this "the BDK way"), or just defining the trait for a single signer and let the caller handle everything else (which is probably also reasonable for a library that is not trying to be a wallet by itself like rust-bitcoin IMHO).

By the way, my personal opinion is that this whole "PSBT workflow" is not really necessary in rust-bitcoin. I guess at some point you have to draw the line and say "this is too high level for this library". IMHO rust-bitcoin should just be "low level stuff" for bitcoin. Even signing is not there (afaik), which totally makes sense to me. You have all the utilities that allows you to build a signer, so it's not necessary to have one right in the library. As long as you have a nice way to build, inspect and extract psbts it's probably fine. But that's just my two cents, and I haven't really followed the discussion, so I might also have missed something. In that case, I'll happily change my mind!

from bdk.

I see. Tbh, I was kinda surprised by bdk suddenly exisiting ^^ so adding these traits would have been part of a longer term effort to get wallet building blocks in there. But you are probably right, these are best kept in another crate given the real world complexities.

from bdk.

This has been open for a while and we've seen that most of the discussion in the rust-bitcoin repo went nowhere, so we are closing this for now...

from bdk.