bitcoin
Draft for Extra Data / HASH160 Support
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.
@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)?
I would also be curious whether you intend this to be a separate BIP or whether it should be added to BIP-119.
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: @.***>
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).
