Draft for Extra Data / HASH160 Support #1587

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: member

@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: contributor

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

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

in bip-0119.2.mediawiki:2 in 144d6179d6

   0 | @@ -0,0 +1,184 @@
   1 | +<pre>
   2 | +  BIP: 119.2 (Pending Assignment)

murchandamus commented at 3:16 PM on March 21, 2025:

  BIP: 119.2 (Pending Assignment)

We only have edits to existing BIPs and new BIPs. Since this is supposed to be separate from BIP-119, it sounds like this should be:

  BIP: ?

in bip-0119.2.mediawiki:9 in 144d6179d6

   0 | @@ -0,0 +1,184 @@
   1 | +<pre>
   2 | +  BIP: 119.2 (Pending Assignment)
   3 | +  Layer: Consensus (soft fork)
   4 | +  Title: CHECKTEMPLATEVERIFY V2
   5 | +  Author: Jeremy Rubin <j@rubin.io>
   6 | +  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0119
   7 | +  Status: Draft
   8 | +  Type: Standards Track
   9 | +  Created: 2024-05-06

murchandamus commented at 3:17 PM on March 21, 2025:

This date refers to the date of number assignment.

  Created: ?

in bip-0119.2.mediawiki:10 in 144d6179d6

   5 | +  Author: Jeremy Rubin <j@rubin.io>
   6 | +  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0119
   7 | +  Status: Draft
   8 | +  Type: Standards Track
   9 | +  Created: 2024-05-06
  10 | +  License: BSD-3-Clause

murchandamus commented at 3:18 PM on March 21, 2025:

It sounds like this BIP should either have "Replaces: 119" or "Requires: 119"

in bip-0119.2.mediawiki:16 in 144d6179d6

  11 | +</pre>
  12 | +
  13 | +==Abstract==
  14 | +
  15 | +This BIP proposes extensions to OP_CHECKTEMPLATEVERIFY BIP-119 as enhancements
  16 | +for LN Symmetry based constructions which use CTV and CSFS.

murchandamus commented at 3:19 PM on March 21, 2025:

If this builds on CSFS, it would be useful to add "Requires: 348" to the header

in bip-0119.2.mediawiki:37 in 144d6179d6

  32 | +(although, according to BIP-341/342 should not be) placed in the Annex. As CTV
  33 | +does not commit to the annex, additional data can be committed to in an
  34 | +OP_RETURN.  However, OP_RETURNs are inefficient as they require 8 bytes of
  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.

murchandamus commented at 3:22 PM on March 21, 2025:

There seems to be a word missing in "committing to with", perhaps:

Instead, committing to the data with CTV extra values on the stack can avoid these
overheads.

murchandamus commented at 3:32 PM on March 21, 2025: contributor

Hi, I just wanted to check in and ask whether there was progress on determining whether this should be a new BIP or an amendment to BIP119. From an editorial perspective, it is currently missing a Copyright and Backwards Compatibility section, and a Rationale section could be used to collect explanations such as the one given in response to @ProofOfKeags’s question

JeremyRubin closed this on Mar 21, 2025