Draft for Extra Data / HASH160 Support

[JeremyRubin]

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.

[jonatack]

@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)?

[murchandamus]

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

[JeremyRubin]

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 <#1587 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGYN67QZGV2C6G7QF5KOO3ZCJK4TAVCNFSM6AAAAABHJE4DU2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMJQHA3TKOBWGM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[reardencode]

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).

[ProofOfKeags]

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]

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]

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!