Draft for Extra Data / HASH160 Support #1587

pull JeremyRubin wants to merge 2 commits into bitcoin:master from JeremyRubin:ctv-v2 changing 1 files +184 −0

JeremyRubin commented at 2:30 pm on May 6, 2024: contributor

This adds support for 3 new modes to CTV:

20 Bytes HASH160 21 Bytes HASH160 + ExtraData 33 Bytes Sha256 + ExtraData

This allows LN Symmetry users to use less space and include extra data in any CSFS without enabling OP_CAT or Vectorized CSFS.
Add 119.2 draft 44f09989a4
jonatack commented at 5:43 pm on May 6, 2024: contributor

@JeremyRubin would you please add a link to the required mailing discussion (and would it make sense to append this information to the BIP119 draft instead)?
BIP-119.2 Properly Trim CTV Flags w/ 21/33 byte version 144d6179d6
murchandamus added the label PR Author action required on May 9, 2024
luke-jr renamed this:
~~119.2 Draft for Extra Data / HASH160 Support~~
Draft for Extra Data / HASH160 Support
on May 10, 2024
murchandamus commented at 6:38 pm on May 14, 2024: contributor

I would also be curious whether you intend this to be a separate BIP or whether it should be added to BIP-119.
JeremyRubin commented at 8:34 pm on May 14, 2024: contributor

It’s definitely not intended to be a part of 119, it’s an extension which is controversial among other options for accomplishing similar tasks (e.g. @reardencode prefers vectorcommit, CSFS multi item, or cat).

On Tue, May 14, 2024, 2:39 PM murchandamus @.***> wrote:

I would also be curious whether you intend this to be a separate BIP or whether it should be added to BIP-119.

— Reply to this email directly, view it on GitHub https://github.com/bitcoin/bips/pull/1587#issuecomment-2110875863, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGYN67QZGV2C6G7QF5KOO3ZCJK4TAVCNFSM6AAAAABHJE4DU2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMJQHA3TKOBWGM . You are receiving this because you were mentioned.Message ID: @.***>
reardencode commented at 10:04 pm on May 14, 2024: none

Thanks for the further prod to comment here.

I’m a big fan of the HASH160 support as it would be appropriate for many protocols.

I’m less of a fan of the concatenation with another stack item while performing CHECKTEMPLATEVERIFY. I could be blinded by my own work and that of @stevenroose in proposing extensions to BIP119 that would use that 33rd byte (in the case of TemplateKey, compatibly with this CVT-v2, but in the case of TXHASH, conflicting with it).
Dragankamil6 approved
in bip-0119.2.mediawiki:40 in 144d6179d6
35+value plus a few VarInts to encode sizes, and use non discounted blockspace. 36+Instead, committing to with CTV extra values on the stack can avoid these 37+overheads. 38+ 39+ 40+==Detailed Specification==
ProofOfKeags commented at 7:56 pm on May 22, 2024:

One of the things I’m having trouble following here is precisely why this extra byte allows for Extra Data to be committed to. As far as I can tell the extra byte ensures that there are at least two stack elements but doesn’t actually verify what the first stack element is.

I assume that CTV’s natural semantics already result in committing to the contents of that second stack element but the mechanism is not obvious to me.

JeremyRubin commented at 8:08 pm on May 22, 2024:

this equation might help:

Sha256(CTVHASH(TX) || sha256(stack[-2])) == stack[-1][0:32]

more or less, check that the 32 bytes on the back of the stack match if you took the CTV hash and hashed it with some extra data.

The point is to enable signing stack[-1][0:32] with CSFS, which then also covers the extra data, allowing you to stuff arbitrary extra data into the witness.

ProofOfKeags commented at 10:30 pm on May 22, 2024:

Ah yes now I see it. I got lost in the noise and didn’t see the -2 at the end here.

I get it now. Thanks for explaining!
jonatack added the label New BIP on Jun 18, 2024

Contributors
JeremyRubin jonatack murchandamus reardencode Dragankamil6 ProofOfKeags

Labels
New BIP PR Author action required