From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 27 May 2026 13:29:37 -0700 Received: from mail-oi1-f183.google.com ([209.85.167.183]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wSKsj-000223-03 for bitcoindev@gnusha.org; Wed, 27 May 2026 13:29:37 -0700 Received: by mail-oi1-f183.google.com with SMTP id 5614622812f47-4829686bb2csf10061018b6e.3 for ; Wed, 27 May 2026 13:29:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1779913770; x=1780518570; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:message-id:to:from:date:sender:from:to:cc:subject:date :message-id:reply-to; bh=aLDmgbVSpkmyfjoXrol6gwDiqxqqnsK6naKAoYiQBRg=; b=cGXTN8EwTM8ddAGO/TO5vo6J/Q20Mv70/z9IBvbPzlYD3So4VsZ1gCekTLeR/M7xBs jCEqxeY0aNPBYMkZ8rZVQ73KaU5L4p4UwMG1aH2NfymOMRFUu+VwjksqgmkQj318pD7z SjVo9hoQ/5hMM4e0GTEzc6n1dzXD7E6yElJWaE5MQlAVITQBUbSId9XecswEVJXNjNxU MsELCllAuh3XASxFuqZOi6p+Jhyk4WzQYyfcBziNxtdXa7CuRS+1zpLYRb6RaveGeHmR UMpdwgywZL5DT5TNLhAPSo0yr9BaGnM8yggjFXC4YuJib3i1L8VYVep05AGM3k/6YBmC JkQA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779913770; x=1780518570; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:message-id:to:from:date:from:to:cc:subject:date:message-id :reply-to; bh=aLDmgbVSpkmyfjoXrol6gwDiqxqqnsK6naKAoYiQBRg=; b=DeoXIYXksxbRvXAsnewgIi9jAnJyC/+zjVzw63T9X01hcHwsFzLBKOyhF0mgD5E1vj igpiXt4lZYjnrJsQnfZj2dZrmnbaGXYMHLU3m2CFb2wIuTZL9TW8HuyoRaMTuryTuvbA w++6g47Qi1LbFSuFJ+HGVXPLegBj50ztnt70eHFKlWTH7AsrRgdUI+2cCncsUUArwCsT jKhojrvk1xlavco/it+ZkCcy5Ov9VP/BskB8VpHSXE6t+Viwue7NkDpFZgmQurcpgk5B ayWA4LzRO8BtBnOXWddWCgnvBoBcMsXQPP1u6C7NEjvWFrxhwl4+dNIgj+UdAaaARehF 64wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779913770; x=1780518570; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:message-id:to:from:date:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=aLDmgbVSpkmyfjoXrol6gwDiqxqqnsK6naKAoYiQBRg=; b=dybDct1ZX4aJ62n1uZ3mwhFqsiLQlypcPkVTOCwsKDnv9MQruJZmWYiPKAntEMSGNV boahyWisQoDh9l4oJ5LZ0n1OQn3XAGgaZtWC1DSWrh/6rMF/AomtyHuTx9NIE7IEZ5T4 75fP90+dsiSe4DCuLiQKliytL0QsEAAAayT55Y5HV+OSxyxI3JiraUID/gOcNiVxn1RX L90QIhvN3LLo7aHeinusHBkRf+0Gr3S6fBBm5J6/iDzMzQzE6ctgI+kCQ4lNMtRzPfii v8OpWS2taL3PS9esYnXzquzt/ODShPsNJyXX2UwO15lzX5wfnPD4uE36QWsAOscuVHSe XFIA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AFNElJ/8mqpfkZazY7SHHjeGWdrQvCTbCuGJkuffL7wPYPbh+MOFxbiCgciIHiaCUk4n38gsE+nQu3eO2bzf@gnusha.org X-Gm-Message-State: AOJu0YyvUADvDvPaud88Gx2kc5/6qV/aq5pIdhFUgtlVhE+/lYesB6AG l0r719C3NOjA4HaLAfSaqFGzo2k+ddpdea+NeNJJTi8deu8oXkNNTw/e X-Received: by 2002:a05:6808:19aa:b0:450:839a:557 with SMTP id 5614622812f47-48549d920e9mr17067842b6e.9.1779913770008; Wed, 27 May 2026 13:29:30 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMM2n8QTOkRPWFnpn42SZquZLj7gr+S7NE7whbv0MZ3EPQ==" Received: by 2002:a05:6870:1788:b0:43b:781c:b5e with SMTP id 586e51a60fabf-43c51ae248cls197595fac.1.-pod-prod-03-us; Wed, 27 May 2026 13:29:24 -0700 (PDT) X-Received: by 2002:a05:6808:238c:b0:482:5ef6:ead3 with SMTP id 5614622812f47-48549ecf95bmr13201782b6e.2.1779913764814; Wed, 27 May 2026 13:29:24 -0700 (PDT) Received: by 2002:a05:690c:a71a:b0:7b3:13f7:5f3a with SMTP id 00721157ae682-7dc3470a1b0ms7b3; Wed, 27 May 2026 12:31:42 -0700 (PDT) X-Received: by 2002:a05:690c:a94:b0:7bd:5b06:5c32 with SMTP id 00721157ae682-7d333bd89fcmr270197187b3.1.1779910301861; Wed, 27 May 2026 12:31:41 -0700 (PDT) Date: Wed, 27 May 2026 12:31:41 -0700 (PDT) From: Josh Doman To: Bitcoin Development Mailing List Message-Id: Subject: [bitcoindev] Mapping the design space of sibling-aware covenants MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_89326_1222516197.1779910301425" X-Original-Sender: joshsdoman@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_89326_1222516197.1779910301425 Content-Type: multipart/alternative; boundary="----=_Part_89327_1570660091.1779910301425" ------=_Part_89327_1570660091.1779910301425 Content-Type: text/plain; charset="UTF-8" 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 * *[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. ------=_Part_89327_1570660091.1779910301425 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Like many others, I'm interested in the OP_CTV and OP_TEMPLATEHASH proposal= s. One subtle difference is that OP_TEMPLATEHASH does not enable sibling-aw= are covenants, like those used in BitVM, Ark, and (potentially) LN-Symmetry= .[1] This requires a connector output and a sibling prevout commitment. Thi= s way, additional conditions can be added to the covenant, or it can be inv= alidated 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 t= o 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 commit= ment to TH:
1.=C2=A0scriptSigs: precompute a hash of all s= criptSigs.
2.=C2=A0Dynamic MuHash: precompute a= MuHash commitment to all indexed prevouts and then remove the prevout at t= he current index.
3.=C2=A0All-but-first: restri= ct execution to the first input and commit to all other prevouts.
4.=C2=A0First-only: commit to the prevout at the first index,= if the current index is non-zero.
5.=C2=A0Next-only: comm= it to the prevout at the next index, if present.

An alternative approach is to create a new witness program, which in= directly enforces a sibling prevout commitment:
6.=C2=A0=C2=A0= Pay-to-Prevout-Anchor (P2PA):=C2=A0an anyone-can-spend output that=C2= =A0cannot be created=C2=A0unless the output's program is the hash of= the prevout at the same index in that transaction.

<= div>The final options involve new introspection opcodes (not exhaustive):
7.=C2=A0OP_TXHASH: a general introspection opcode that can = push a hash that commits to one or more prevouts at specific indices.
=
8.=C2=A0OP_CAT: a simple opcode that enables introspection via = complex script.

I won't go into the pros and con= s of each option, except to say that I think Option 5 strikes a nice balanc= e 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
<= div>
[1] Eliminating the 2x-delay problem in LN-Symmetry= requires a contract-level relative=C2=A0timelock (CLRT) and a sibling-awar= e covenant. CLRT capabilities remain an active area of research and may not= exist in the first iteration of LN-Symmetry.

See:=C2=A0bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/fd2ba4b8-95f6-4541-900a-47bdf65a166cn%40googlegroups.com.
------=_Part_89327_1570660091.1779910301425-- ------=_Part_89326_1222516197.1779910301425--