-
Notifications
You must be signed in to change notification settings - Fork 311
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Require an explicit sighash or default to SIGHASH_ALL
#133
Comments
That's not really a bug, it's the expected behavior (even though there's probably room to discuss whether this is the best behavior or not). Since bdk supports signing with any sighash, it requires the Another option would be to just default to I'll rename this issue so that we can use it to discuss whether or not we should make this change. |
SIGHASH_ALL
I'm all for defaulting to All, and in fact I tried setting it manually to All before. But then it just fails a few lines below with MissingNonWitnessUtxo. This is actually another problem. I think it should be in Segwitv0 instead of Legacy. But how can I create such a PartiallySignedTransaction when using from_unsigned_tx. Should there be a second function, or a parameter to construct a segwit tx? |
Currently bdk decides whether it should sign with If you just create a psbt using In your case you have a fixed WIF key, so you don't actually need the For instance, have a look at the Lines 970 to 1042 in 64b4cfe
|
Cool, thanks for the hints. |
Yeah most of those stuff are private because they are not really polished and they'll probably change as we move forward with the development. I wasn't trying to suggest to use directly That said, I think we could look into exposing those functionalities as a wallet call that takes a raw transaction or a very basic PSBT and tries to add all the metadata it can. I'm pretty sure Bitcoin Core has such a call, and that's definitely something that would be useful. Keep in mind tough that even having that option today wouldn't probably make your test work, since your wallet is an offline wallet, and thus doesn't have the UTXOs that are being spent in its database. This would be something that another online and properly synced co-signer could do, but that's not the case in your example. That's why, generally, those metadata are added directly by the creator of the PSBT: if a wallet picks a UTXO to spend it in a transaction, it means that it also has enough information to add that UTXO as a
Not at all, but BDK needs a full PSBT to sign, not just a raw transaction. Every wallet that can export a PSBT today would work with BDK, or at most it would fail with the
Yes, exactly. Usually PSBTs are encoded in |
Defaulting to Is the worst case for this approach that if the signer meant to not sign for all outputs then their signatures would be invalid? In this case it seems reasonable that the PSBT creator should be required to specify the SigHashType when it is not ALL. |
Yeah apparently that's not only what other wallets do, but also part of the spec. From BIP174, "Data Signers Check For":
|
Thanks for your help and explanations. I could get my example working by using a deserialized psbt from electrum. |
That's pretty much what this issue is all about: BDK requires having an explicit sighash but other wallets don't usually set that field. The spec also says that a wallet should default to SIGHASH_ALL if it's not provided, so we'll update BDK accordingly. In the end you'll just be able to sign PSBTs directly from wallets like Electrum, Bitcoin Core, etc without having to modify them before. |
Simplification of instruction iterators use by descriptors
I fail to get a transaction signed for a multisig P2WSH-P2SH wallet.
To illustrate what I am trying to do, I created a test at the bottom of:
https://github.com/ulrichard/bdk/blob/sign_multi_p2wsh_p2sh/src/wallet/mod.rs
When I debug into the sign function, it fails in ComputeSighash for Legacy with MissingSighash.
Am I doing something wrong, or is this a bug in bdk?
If something is missing in bdk, I am willing to give it a try implementing it. But I would need some guidance for that.
The text was updated successfully, but these errors were encountered: