Mapping the design space of sibling-aware covenants
3 messages, 27 to 28 May 2026. Started by Josh Doman.
Josh Doman (2), Greg Sanders
Like many others, I'm interested in the OP_CTV and OP_TEMPLATEHASH proposals. One subtle difference is that OP_TEMPLATEHASH does not enable sibling-aware covenants, like those used in BitVM, Ark, and (potentially) LN-Symmetry.[1] This requires a connector output and a sibling prevout commitment. This way, additional conditions can be added to the covenant, or it can be invalidated altogether.
Personally, I find unsatisfactory the method by which OP_CTV achieves this (by committing to the scriptSigs), and I appreciate the simplicity of OP_TEMPLATEHASH (TH) and the fact that it requires no additional pre-computation.
The purpose of this post isn't to suggest a modification to TH but to attempt to list all the ways sibling-aware covenants could be achieved. I found this helpful to understand the tradeoffs that surround this capability.
The first five options entail an additional commitment to TH: 1.* scriptSigs*: precompute a hash of all scriptSigs. 2. *Dynamic MuHash*: precompute a MuHash commitment to all indexed prevouts and then remove the prevout at the current index. 3. *All-but-first*: restrict execution to the first input and commit to all other prevouts. 4. *First-only*: commit to the prevout at the first index, if the current index is non-zero. 5. *Next-only*: commit to the prevout at the next index, if present.
An alternative approach is to create a new witness program, which indirectly enforces a sibling prevout commitment: 6. * Pay-to-Prevout-Anchor (P2PA):* an anyone-can-spend output that *cannot be created *unless the output's program is the hash of the prevout at the same index in that transaction.
The final options involve new introspection opcodes (not exhaustive): 7. *OP_TXHASH*: a general introspection opcode that can push a hash that commits to one or more prevouts at specific indices. 8. *OP_CAT*: a simple opcode that enables introspection via complex script.
I won't go into the pros and cons of each option, except to say that I think Option 5 strikes a nice balance between minimalism, pragmatism, and flexibility.[2]
Mostly, I wanted to list what options I think exist. If I missed any, please let me know!
Best, Josh
*[1] Eliminating the 2x-delay problem in LN-Symmetry requires a contract-level relative timelock (CLRT) and a sibling-aware covenant. CLRT capabilities remain an active area of research and may not exist in the first iteration of LN-Symmetry.*
*See: https://delvingbitcoin.org/t/contract-level-relative-timelocks-or-lets-talk-about-ancestry-proofs-and-singletons/1353 <https://delvingbitcoin.org/t/contract-level-relative-timelocks-or-lets-talk-about-ancestry-proofs-and-singletons/1353>*
*[2] Option 5 (Next-Only) strikes me as a balanced option for several reasons:* *- Identical to TH in the common single-input use case.* *- Solves for the two-input sibling-aware covenant common to L2 protocols.* *- Leaves the door open to multi-input covenants with no sibling commitments.* *- Requires no additional pre-computation.*
Quoted text (1 line)
> Ark
Can you remind me in what way Ark would benefit from sibling commitments?
Greg
On Wednesday, May 27, 2026 at 4:29:30 PM UTC-4 Josh Doman wrote:
Quoted text (66 lines)
> Like many others, I'm interested in the OP_CTV and OP_TEMPLATEHASH > proposals. One subtle difference is that OP_TEMPLATEHASH does not enable > sibling-aware covenants, like those used in BitVM, Ark, and (potentially) > LN-Symmetry.[1] This requires a connector output and a sibling prevout > commitment. This way, additional conditions can be added to the covenant, > or it can be invalidated altogether. > > Personally, I find unsatisfactory the method by which OP_CTV achieves this > (by committing to the scriptSigs), and I appreciate the simplicity of > OP_TEMPLATEHASH (TH) and the fact that it requires no additional > pre-computation. > > The purpose of this post isn't to suggest a modification to TH but to > attempt to list all the ways sibling-aware covenants could be achieved. I > found this helpful to understand the tradeoffs that surround this > capability. > > The first five options entail an additional commitment to TH: > 1.* scriptSigs*: precompute a hash of all scriptSigs. > 2. *Dynamic MuHash*: precompute a MuHash commitment to all indexed > prevouts and then remove the prevout at the current index. > 3. *All-but-first*: restrict execution to the first input and commit to > all other prevouts. > 4. *First-only*: commit to the prevout at the first index, if the current > index is non-zero. > 5. *Next-only*: commit to the prevout at the next index, if present. > > An alternative approach is to create a new witness program, which > indirectly enforces a sibling prevout commitment: > 6. * Pay-to-Prevout-Anchor (P2PA):* an anyone-can-spend output that *cannot > be created *unless the output's program is the hash of the prevout at the > same index in that transaction. > > The final options involve new introspection opcodes (not exhaustive): > 7. *OP_TXHASH*: a general introspection opcode that can push a hash that > commits to one or more prevouts at specific indices. > 8. *OP_CAT*: a simple opcode that enables introspection via complex > script. > > I won't go into the pros and cons of each option, except to say that I > think Option 5 strikes a nice balance between minimalism, pragmatism, and > flexibility.[2] > > Mostly, I wanted to list what options I think exist. If I missed any, > please let me know! > > Best, > Josh > > *[1] Eliminating the 2x-delay problem in LN-Symmetry requires a > contract-level relative timelock (CLRT) and a sibling-aware covenant. CLRT > capabilities remain an active area of research and may not exist in the > first iteration of LN-Symmetry.* > > *See: https://delvingbitcoin.org/t/contract-level-relative-timelocks-or-lets-talk-about-ancestry-proofs-and-singletons/1353 > <https://delvingbitcoin.org/t/contract-level-relative-timelocks-or-lets-talk-about-ancestry-proofs-and-singletons/1353>* > > *[2] Option 5 (Next-Only) strikes me as a balanced option for several > reasons:* > *- Identical to TH in the common single-input use case.* > *- Solves for the two-input sibling-aware covenant common to L2 protocols.* > *- Leaves the door open to multi-input covenants with no sibling > commitments.* > *- Requires no additional pre-computation.* > >
Quoted text (1 line)
> Can you remind me in what way Ark would benefit from sibling commitments?
In all honesty, sibling commitments have minimal benefit to Ark, so in retrospect, it is not a great example.
The only place sibling commitments could theoretically benefit Ark is by reducing the cost of spending a connector output, since each connector output is created in advance to be spent by a specific forfeit transaction (for an on-chain withdrawal).
Realizing the cost savings, though, would require an explicit Pay-to-Bare-Tapscript or Pay-to-TemplateHash witness program, akin to bare CTV. This would save ~16vb, but only in the rare event the operator needs to publish the forfeit transaction.
Josh
* (1) and (2) are only compatible with script-based vector commitments, since tapleaf commitments would create a hash cycle.
On Thu, May 28, 2026 at 10:14 AM Greg Sanders <gsanders87@gmail•com> wrote:
Quoted text (86 lines)
> > Ark > > Can you remind me in what way Ark would benefit from sibling commitments? > > Greg > > On Wednesday, May 27, 2026 at 4:29:30 PM UTC-4 Josh Doman wrote: > >> Like many others, I'm interested in the OP_CTV and OP_TEMPLATEHASH >> proposals. One subtle difference is that OP_TEMPLATEHASH does not enable >> sibling-aware covenants, like those used in BitVM, Ark, and (potentially) >> LN-Symmetry.[1] This requires a connector output and a sibling prevout >> commitment. This way, additional conditions can be added to the covenant, >> or it can be invalidated altogether. >> >> Personally, I find unsatisfactory the method by which OP_CTV achieves >> this (by committing to the scriptSigs), and I appreciate the simplicity of >> OP_TEMPLATEHASH (TH) and the fact that it requires no additional >> pre-computation. >> >> The purpose of this post isn't to suggest a modification to TH but to >> attempt to list all the ways sibling-aware covenants could be achieved. I >> found this helpful to understand the tradeoffs that surround this >> capability. >> >> The first five options entail an additional commitment to TH: >> 1.* scriptSigs*: precompute a hash of all scriptSigs. >> 2. *Dynamic MuHash*: precompute a MuHash commitment to all indexed >> prevouts and then remove the prevout at the current index. >> 3. *All-but-first*: restrict execution to the first input and commit to >> all other prevouts. >> 4. *First-only*: commit to the prevout at the first index, if the >> current index is non-zero. >> 5. *Next-only*: commit to the prevout at the next index, if present. >> >> An alternative approach is to create a new witness program, which >> indirectly enforces a sibling prevout commitment: >> 6. * Pay-to-Prevout-Anchor (P2PA):* an anyone-can-spend output that *cannot >> be created *unless the output's program is the hash of the prevout at >> the same index in that transaction. >> >> The final options involve new introspection opcodes (not exhaustive): >> 7. *OP_TXHASH*: a general introspection opcode that can push a hash that >> commits to one or more prevouts at specific indices. >> 8. *OP_CAT*: a simple opcode that enables introspection via complex >> script. >> >> I won't go into the pros and cons of each option, except to say that I >> think Option 5 strikes a nice balance between minimalism, pragmatism, and >> flexibility.[2] >> >> Mostly, I wanted to list what options I think exist. If I missed any, >> please let me know! >> >> Best, >> Josh >> >> *[1] Eliminating the 2x-delay problem in LN-Symmetry requires a >> contract-level relative timelock (CLRT) and a sibling-aware covenant. CLRT >> capabilities remain an active area of research and may not exist in the >> first iteration of LN-Symmetry.* >> >> *See: https://delvingbitcoin.org/t/contract-level-relative-timelocks-or-lets-talk-about-ancestry-proofs-and-singletons/1353 >> <https://delvingbitcoin.org/t/contract-level-relative-timelocks-or-lets-talk-about-ancestry-proofs-and-singletons/1353>* >> >> *[2] Option 5 (Next-Only) strikes me as a balanced option for several >> reasons:* >> *- Identical to TH in the common single-input use case.* >> *- Solves for the two-input sibling-aware covenant common to L2 >> protocols.* >> *- Leaves the door open to multi-input covenants with no sibling >> commitments.* >> *- Requires no additional pre-computation.* >> >> -- > You received this message because you are subscribed to a topic in the > Google Groups "Bitcoin Development Mailing List" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/bitcoindev/uyRpzE6IFOQ/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > bitcoindev+unsubscribe@googlegroups•com. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/c00f0fdf-950b-4ff8-a502-eeb1be02c510n%40googlegroups.com > <https://groups.google.com/d/msgid/bitcoindev/c00f0fdf-950b-4ff8-a502-eeb1be02c510n%40googlegroups.com?utm_medium=email&utm_source=footer> > . >