[bitcoindev] Mapping the design space of sibling-aware covenants

[bitcoindev] Mapping the design space of sibling-aware covenants

[Josh Doman]

[-- Attachment #1.1: Type: text/plain, Size: 3414 bytes --]

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 the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/fd2ba4b8-95f6-4541-900a-47bdf65a166cn%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 4224 bytes --]

[bitcoindev] Re: Mapping the design space of sibling-aware covenants

[Greg Sanders]

[-- Attachment #1.1: Type: text/plain, Size: 3772 bytes --]

> 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 the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, 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.

[-- Attachment #1.2: Type: text/html, Size: 4938 bytes --]

Re: [bitcoindev] Re: Mapping the design space of sibling-aware covenants

[Josh Doman]

[-- Attachment #1: Type: text/plain, Size: 5413 bytes --]

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

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

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAB3%3D21nrvi-XyiXom9aNvVe9Ri59ugjj%3D_WG2wgYMWiGaFQxjA%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 7016 bytes --]