-
Notifications
You must be signed in to change notification settings - Fork 137
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
PSBT v2 #330
PSBT v2 #330
Conversation
76fb7dd
to
8c7ec7f
Compare
71ad950
to
b8b79a3
Compare
9c7afdb
to
7d035ed
Compare
56aa789
to
f8dac44
Compare
5a14d04
to
26aef05
Compare
742652e
to
df3e69a
Compare
Co-authored-by: Jon Griffiths <[email protected]>
The addition of new allocations for v2 inputs and outputs means the error handling logic must be updated. Some new checks are needed for v2 which in the v0 path are caught by the tx modification path. Additionally, there was a long-existing bug in the old code where memory allocation failure would cause the number of in/outputs to be off-by-one.
This flag allows internal functions to be exposed through the Python CFFI tests.
This follows the convention that cryptographically unfortunate or malicious inputs are rejected with this error, allow the caller to retry with new inputs. In the Elements case where ECDH is used during blinding, this indicates that a new ephemeral key should be generated, for example.
This allows SWIG exposed languages to avoid a lot of boilerplate copying txout values over.
Some shared-blinding scenarios require them.
Also fix compilation for non-elements builds.
As noted, these calls may be used for other purposes by callers.
5f405e2
to
e1fc3cd
Compare
I'm happy to call it a utack and iterate/fix-forward as required. (e1fc3cd) |
Oops, I missed this :-) When trying to bump to v0.8.6 in LibWallySwift, something did break and I didn't find CHANGES.md very clear on what to do:
|
@Sjors This interface is because most wrapped languages can't return a reference to sub-objects once they are embedded in a parent (shared ownership semantics don't transfer well, and taking/returning sub-objects by value is very inefficient). I'm not against adding getters for the sub-objects for non-swig wrapped language use although it may be a while before I have time to so so. |
I ended up using |
The secp256k1-zkp submodule at CLibWally/libwally-core/src/secp256k1 is updated along with libwally-core. In build-libwally.sh script we switch back to a vanilla libwally at the same commit that Bitcoin Core uses. Although Bitcoin Core bumped that commit a few months ago, we don't change it here because secp256k1-zkp has not yet been rebased on it. There were two breaking change in libwally-core: 1. wally_psbt_from_bytes got an additional FLAGS argument in 0fb94751def8b2c767680e2428ebe2fdabd436c7 (ElementsProject/libwally-core#336): trivially fixed by setting it to 0 2. wally_psbt_output no longer has a witness_script field as of 8f8481a3c509fc4a02425db3839f92594e6ea852 (ElementsProject/libwally-core#330). This required a more tedious workaround.
The secp256k1-zkp submodule at CLibWally/libwally-core/src/secp256k1 is updated along with libwally-core. In build-libwally.sh script we switch back to a vanilla libwally at the same commit that Bitcoin Core uses. Although Bitcoin Core bumped that commit a few months ago, we don't change it here because secp256k1-zkp has not yet been rebased on it. There were two breaking change in libwally-core: 1. wally_psbt_from_bytes got an additional FLAGS argument in 0fb94751def8b2c767680e2428ebe2fdabd436c7 (ElementsProject/libwally-core#336): trivially fixed by setting it to 0 2. wally_psbt_output no longer has a witness_script field as of 8f8481a3c509fc4a02425db3839f92594e6ea852 (ElementsProject/libwally-core#330). This required a more tedious workaround.
No description provided.