Rewrite bundle BIP

[darosior]

This is to address bitcoin#1974 (comment). It largely reuses language from my merge PoC, and addresses the comment Greg made there (darosior@c9783a2#r178104563). This also reworks the motivation and rationale a bit, notably the BitVM2 improvement as motivation for CSFS was dated, and the rationale for why TH rather than CTV was redundant with BIP 446 so i added a brief sentence and pointed to the rationale section of 446 instead.

[murchandamus]

Thanks for working on this

[murchandamus]

Weren’t you gonna call it Twine?

[darosior]

'Twine' was yet another attempt at something that could make sense as a name. but i don't think we should pick a name unless it appears like an evidence to all co-authors. Twine makes sense but isnt quite that. The "for more" was intentional because it points to both more detail *and* more reasons.

…

-------- Original Message --------

On Tuesday, 03/10/26 at 17:54 murchandamus ***@***.***> wrote: @murchandamus commented on this pull request. Thanks for working on this --------------------------------------------------------------- In [bip-templatehash-csfs-ik.md](#2 (comment)): > @@ -1,7 +1,7 @@ ``` BIP: ? Layer: Consensus (soft fork) - Title: Next-transaction and Rebindable Signatures + Title: a Taproot-native (re)bindable transaction proposal Weren’t you gonna call it Twine? --------------------------------------------------------------- In [bip-templatehash-csfs-ik.md](#2 (comment)): > +an increased risk surface, notably in terms of implementation complexity. As the additional capabilities have not been +demonstrated to enable new important use cases or substantially improve existing ones, this proposal favours the minimal +approach. Maybe: ⬇️ Suggested change -an increased risk surface, notably in terms of implementation complexity. As the additional capabilities have not been -demonstrated to enable new important use cases or substantially improve existing ones, this proposal favours the minimal -approach. +an increased risk surface, notably in terms of implementation complexity. As the additional capabilities have not been +demonstrated to enable new important use cases or substantially improve existing ones beyond this proposal, this proposal favours the minimal +approach. --------------------------------------------------------------- In [bip-templatehash-csfs-ik.md](#2 (comment)): > -## Implementation - -[`OP_TEMPLATEHASH`][templatehash-bip], [`BIP348 OP_CHECKSIGFROMSTACK`][csfs-bip], and [`BIP349 OP_INTERNALKEY`][internalkey-bip] implemented as specified in their corresponding documents. +An alternative to [BIP 446 `OP_TEMPLATEHASH`][templatehash-bip] is [BIP 119 `OP_CHECKTEMPLATEVERIFY`][ctv-bip]. This +proposal favours the minimal approach of [BIP 446 `OP_TEMPLATEHASH`][templatehash-bip] that does not modifiy legacy +scripting contexts and reuses the existing Taproot signature hashes. See [the rationale section of BIP +446][templatehash-rationale] for more. ⬇️ Suggested change -446][templatehash-rationale] for more. +446][templatehash-rationale] for more details. — Reply to this email directly, [view it on GitHub](#2 (review)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AFLK3F6TJHODKAFRBTTIEVD4QCFINAVCNFSM6AAAAACWNOX7KOVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZTSMRVGYZTCMRZGU). You are receiving this because you authored the thread.Message ID: ***@***.***>

[instagibbs]

it appears like an evidence to all co-authors

eh?

concept ACK, I think murch's suggestions can be taken

[darosior]

"Appears like an evidence" is a Frenchism, my bad.

I meant "unless it appears as the obvious right name to all co-authors". :-)

[darosior]

Took Murch's suggestions outside of the name change.

[instagibbs]

taken, thanks