This refactors `compute_control_block` to improve performance, and make
the function simpler to read (to me at least).
The previous version walked the entire script tree searching for the
first matching instance of the leaf node.
The new version expects the caller to pass in an explicit `path`
parameter, which tells us exactly where the leaf node lives, with
left/right steps encoded as bits in an integer. We walk down the
tree straight to that leaf node, and build the control block as we go.
This might not be the best DX for a real-world API or library, but this
is just reference code, so we can accept poor usage ergonomics if it makes
the code clearer and more explicit.
This proposal appears abandoned, as it has not had any updates in over
four years, and cursory search did not produce any public discussions of
it since it was published either. Attempts to contact the authors did
not receive a response within four weeks.
The receiver-to-sender response section presented HPKE encryption and
POST as the only path, when v2 receivers servicing v1 (BIP 78) senders
in the wild send the cleartext base64 PSBT via PUT to their own mailbox.
Add a forward-reference from the v2 path to Backwards compatibility,
and specify the v1-fallback response (no HPKE; PUT method; UTF-8 body;
receiver's own mailbox as target) normatively in that section.
Addresses payjoin/rust-payjoin#1487. Partially addresses
payjoin/rust-payjoin#844 (PUT/POST gap).
This commit clarifies that even for Proof of Funds signatures the
sequence of the first input is considered as "age S".
The reasoning behind this is that only the first input is a synthetic
one that doesn't reference a real transaction to which the height could
be compared against. Even though the Proof of Funds inputs could have
higher sequence values, those heights might have already been long
reached and would make the sequence values irrelevant compared to the potential
restrictions in the challenge script.
This is cleaning up an artifact that was left over from #1352.
The alternative to removing the optionality of the address
would be to assume OP_TRUE in case of an empty address.
But that sounds like it could open up any number of potential
vulnerabilities.
And a user still has the ability to use an OP_TRUE script
in a p2wsh or p2tr address.
* Update bip-0343.mediawiki
As a co-author I would like to move this BIP's status to Closed due to its current irrelevance and lack of any known deployments on the network.
If I could I would delete it fully, or better yet go back in time to prevent it from being written.
* bip343: Fix table entry for move to Closed
* bip343: Record Close reason
---------
Co-authored-by: Murch <murch@murch.one>
Note that the Input Finalizer retains PSBT_IN_PROPRIETARY fields it does
not understand, treating them like unknown fields so it does not clear
proprietary data it cannot interpret.
This mirrors the existing PSBT_IN_SIGHASH_TYPE constraint from the
per-input field description. Added to the Input Finalizer section so it
is not missed.
* BIP: OP_TWEAKADD
* BIP TweakAdd: note on commutativity of tweaking and add test cases
* BIP TweakAdd: Invert Argument Order
* BIP Tweakadd: fix typo & add note on even-y tweaking
* BIP TweakAdd -- add mailing list discussion
* BIP TweakAdd: Add Alpen and MATT mentions
* BIP TweakAdd Formatting Edits
* BIP TWEAKADD remove conventions section
* BIP TWEAKADD formatting fix
* BIP TWEAKADD Move Vectors to end
* BIP TweakAdd: Condense compatibility section
* [BIP-0449] Updates post assignemnt
* [BIP-0449] Normalize Metadata
* Update bip-0449.md Link Text to point to OP of ML Thread
