- Apply BIP-0440 wordspan notation to numeric and bitvector costs.
- Define OP_RIGHT as rightmost-byte extraction with bounded copying cost.
- Clarify OP_UPSHIFT, CLTV/CSV, and final success-check costs.
Standardizes all P2MR-specific functions to use bytes uniformly for
input/output. Hex conversions are now confined to two boundaries:
reading `script` field out of ScriptTree input, and comparing against
hex-encoded test vector data in `run_single_test`.
bech32 functions and s2w are left unchanged.
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>
