From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 28 May 2026 07:14:56 -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 1wSbVg-000273-9L for bitcoindev@gnusha.org; Thu, 28 May 2026 07:14:56 -0700 Received: by mail-oi1-f183.google.com with SMTP id 5614622812f47-4853c190ca0sf5372013b6e.0 for ; Thu, 28 May 2026 07:14:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1779977690; x=1780582490; 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:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=1/IQOXWqhczOiBvZUXw2+4m0yxv8W9fGJlPDPWROOps=; b=ZUnRdb+ok0wYrZBFWd3ohcUR5RVVAod08QF7ta6qy8F+ZdFcC8jYsyxQyKxdPkMEhq jPzNmoCjqUl01q4aomxIrZZ4/4XKM+P6eF9GiaWb20JoR3BluEUSxr8JV9dqb8wLNqZm BP8/iRCMLRywC43Nmz20alFlNe1O8vmCQcLO9/zVU8A0Ds0ogOc9eGbRHs175ovB0GvX HI9IJOwR1hqdiSCja9AgZBb5543NBnbOlesDryOgRE7hb1BEd9uRAURrRznQzO7E9lg1 XJSKHUTdWI5LNra8vZlNmjWUvoZ/3yvXCW3SAlyEcTAHJMTin88FdYmpJsSoQ8H+GZdC d67A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779977690; x=1780582490; 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:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=1/IQOXWqhczOiBvZUXw2+4m0yxv8W9fGJlPDPWROOps=; b=GSvnT7/+8+3KMQXQ6tmLQB6SqrAyo4sOaV0l1Vi1LzvBTe8W28AAnprF/LvWhcjHba FTZvNB1s3FtD9gLhauZEAX5Fp3+4RB0bDj4+5JsciblYfsd4Do6VVXRdvBJzLyrVtesI +/w46qT8WIbkEWvikH4SPZjKjyfmvmFFD0tCA/x4KYdjS+mkyjEfSnrk9BZCtfay/fHp QBef9XMqXYZm+NmkkGwD3zdOzXGrV18OoIGDmvne4SwGgeZjy4u0k7PBMGrhrDMyTb8S fbCG9o/EULaceGXZPODreTmHd+x2A3c5sAJXlzPS+nU81MOy4nKjvJUrcPhMkuch5eGI ezUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779977690; x=1780582490; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=1/IQOXWqhczOiBvZUXw2+4m0yxv8W9fGJlPDPWROOps=; b=h3NuL0Ot3UT/hP+jZdnIGQdECs/pkTjjU/VAmkqNOZNJoCQYuUY1zqyFome29rL3rE wYH31F8wTzWtrXiFinZFinNH/AZ2UMvi3P0WDEe0ejuJCMpgl6snoNdqWUCfFzBjbBwe kudEn8oSjictxufYOVx8pdBz+yBm1KwT3HDNb5C7eXNUUEsHBSNK9GugfVcJcJgn1SZy xe6m5v2a54ZDLUgEygkzXczQ0UmDPf3/Ni1eShjmFQFA/fTUM0c3A8nY1TnpQTcZ2SqS rDGic8vVLnsWOqj/EkVKizR5TaBfX/CF4oy7J69YlZJiQWQgijvKu1I/NNFYS5lhuTRV TPlQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AFNElJ8KIZ80EeaPL1zpMp+NOAMV0enho56SnBD92wA3SqbrRTieLfohYs/pfVbmBFgGoUj0exN8cojs556F@gnusha.org X-Gm-Message-State: AOJu0YzUeGk8FaNGEEiRhyGe7McpTwEQS6KTASfxc0kck8vwXVP6ucCt gqhN00w7OT7f5Jdh2eWennq+ur5LHp35ZKS77QrkCQwTG1LJpkhSnW+a X-Received: by 2002:a05:6808:c18a:b0:485:a9b2:5457 with SMTP id 5614622812f47-485a9b255c4mr7866914b6e.35.1779977689896; Thu, 28 May 2026 07:14:49 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMO8QPteU+RJlHZmyqn1pUUZS7qjou53pQcoL5mfeE0LbQ==" Received: by 2002:a05:6871:c886:20b0:416:1b5c:16df with SMTP id 586e51a60fabf-43c51b46196ls581064fac.2.-pod-prod-08-us; Thu, 28 May 2026 07:14:44 -0700 (PDT) X-Received: by 2002:a05:6808:1719:b0:482:c65c:457e with SMTP id 5614622812f47-4854a0ead12mr15840912b6e.11.1779977684252; Thu, 28 May 2026 07:14:44 -0700 (PDT) Received: by 2002:a05:690c:a4c5:b0:7ba:f1b3:9504 with SMTP id 00721157ae682-7dc34edb97bms7b3; Thu, 28 May 2026 07:04:25 -0700 (PDT) X-Received: by 2002:a05:690c:e351:b0:7dc:9693:57b0 with SMTP id 00721157ae682-7dc96935b12mr29635617b3.42.1779977065329; Thu, 28 May 2026 07:04:25 -0700 (PDT) Date: Thu, 28 May 2026 07:04:24 -0700 (PDT) From: Greg Sanders To: Bitcoin Development Mailing List Message-Id: In-Reply-To: References: Subject: [bitcoindev] Re: Mapping the design space of sibling-aware covenants MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_118248_423545524.1779977064878" X-Original-Sender: gsanders87@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_118248_423545524.1779977064878 Content-Type: multipart/alternative; boundary="----=_Part_118249_1150385858.1779977064878" ------=_Part_118249_1150385858.1779977064878 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Ark Can you remind me in what way Ark would benefit from sibling commitments?= =20 Greg On Wednesday, May 27, 2026 at 4:29:30=E2=80=AFPM UTC-4 Josh Doman wrote: > Like many others, I'm interested in the OP_CTV and OP_TEMPLATEHASH=20 > proposals. One subtle difference is that OP_TEMPLATEHASH does not enable= =20 > sibling-aware covenants, like those used in BitVM, Ark, and (potentially)= =20 > LN-Symmetry.[1] This requires a connector output and a sibling prevout=20 > commitment. This way, additional conditions can be added to the covenant,= =20 > or it can be invalidated altogether. > > Personally, I find unsatisfactory the method by which OP_CTV achieves thi= s=20 > (by committing to the scriptSigs), and I appreciate the simplicity of=20 > OP_TEMPLATEHASH (TH) and the fact that it requires no additional=20 > pre-computation. > > The purpose of this post isn't to suggest a modification to TH but to=20 > attempt to list all the ways sibling-aware covenants could be achieved. I= =20 > found this helpful to understand the tradeoffs that surround this=20 > 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=20 > prevouts and then remove the prevout at the current index. > 3. *All-but-first*: restrict execution to the first input and commit to= =20 > all other prevouts. > 4. *First-only*: commit to the prevout at the first index, if the current= =20 > 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=20 > indirectly enforces a sibling prevout commitment: > 6. * Pay-to-Prevout-Anchor (P2PA):* an anyone-can-spend output that *cann= ot=20 > be created *unless the output's program is the hash of the prevout at the= =20 > 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= =20 > commits to one or more prevouts at specific indices. > 8. *OP_CAT*: a simple opcode that enables introspection via complex=20 > script. > > I won't go into the pros and cons of each option, except to say that I=20 > think Option 5 strikes a nice balance between minimalism, pragmatism, and= =20 > flexibility.[2] > > Mostly, I wanted to list what options I think exist. If I missed any,=20 > please let me know! > > Best, > Josh > > *[1] Eliminating the 2x-delay problem in LN-Symmetry requires a=20 > contract-level relative timelock (CLRT) and a sibling-aware covenant. CLR= T=20 > capabilities remain an active area of research and may not exist in the= =20 > first iteration of LN-Symmetry.* > > *See: https://delvingbitcoin.org/t/contract-level-relative-timelocks-or-l= ets-talk-about-ancestry-proofs-and-singletons/1353=20 > * > > *[2] Option 5 (Next-Only) strikes me as a balanced option for several=20 > 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=20 > commitments.* > *- Requires no additional pre-computation.* > > --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= c00f0fdf-950b-4ff8-a502-eeb1be02c510n%40googlegroups.com. ------=_Part_118249_1150385858.1779977064878 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Ark

Can you remind me in what way Ark would benef= it from sibling commitments?=C2=A0

Greg
= On Wednesday, May 27, 2026 at 4:29:30=E2=80=AFPM UTC-4 Josh Doman wrote:
Like many other= s, I'm interested in the OP_CTV and OP_TEMPLATEHASH proposals. One subt= le difference is that OP_TEMPLATEHASH does not enable sibling-aware covenan= ts, like those used in BitVM, Ark, and (potentially) LN-Symmetry.[1] This r= equires a connector output and a sibling prevout commitment. This way, addi= tional conditions can be added to the covenant, or it can be invalidated al= together.

Personally, I find unsatisfactory the method b= y which OP_CTV achieves this (by committing to the scriptSigs), and I appre= ciate 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.=C2=A0scriptSigs: precompute a hash of all scriptSigs.
2.=C2=A0Dynamic MuHash: precompute a MuHash commitm= ent to all indexed prevouts and then remove the prevout at the current inde= x.
3.=C2=A0All-but-first: restrict execution to= the first input and commit to all other prevouts.
4.=C2=A0= First-only: commit to the prevout at the first index, if the current= index is non-zero.
5.=C2=A0Next-only: commit to the prevo= ut at the next index, if present.

An alterna= tive approach is to create a new witness program, which indirectly enforces= a sibling prevout commitment:
6.=C2=A0=C2=A0Pay-to-Prevout-An= chor (P2PA):=C2=A0an anyone-can-spend output that=C2=A0cannot be cre= ated=C2=A0unless the output's program is the hash of the prevout at= the same index in that transaction.

The final opt= ions involve new introspection opcodes (not exhaustive):
7.=C2=A0= OP_TXHASH: a general introspection opcode that can push a hash that = commits to one or more prevouts at specific indices.
8.=C2=A0O= P_CAT: a simple opcode that enables introspection via complex script.

I won't go into the pros and cons of each optio= n, except to say that I think Option 5 strikes a nice balance between minim= alism, pragmatism, and flexibility.[2]

Mostly, I w= anted to list what options I think exist. If I missed any, please let me kn= ow!

Best,
Josh

= [1] Eliminating the 2x-delay problem in LN-Symmetry requires a contract-= level relative=C2=A0timelock (CLRT) and a sibling-aware covenant. CLRT capa= bilities remain an active area of research and may not exist in the first i= teration of LN-Symmetry.

See:=C2=A0<= a href=3D"https://delvingbitcoin.org/t/contract-level-relative-timelocks-or= -lets-talk-about-ancestry-proofs-and-singletons/1353" target=3D"_blank" rel= =3D"nofollow" data-saferedirecturl=3D"https://www.google.com/url?hl=3Den&am= p;q=3Dhttps://delvingbitcoin.org/t/contract-level-relative-timelocks-or-let= s-talk-about-ancestry-proofs-and-singletons/1353&source=3Dgmail&ust= =3D1780058743044000&usg=3DAOvVaw2qi3iEBpNngUEsvuQS53Iw">https://delving= bitcoin.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 protoc= ols.
- Leaves the door open to multi-input covenants with = no sibling commitments.
- Requires no additional pre-compu= tation.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/c00f0fdf-950b-4ff8-a502-eeb1be02c510n%40googlegroups.com.
------=_Part_118249_1150385858.1779977064878-- ------=_Part_118248_423545524.1779977064878--