From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 28 May 2026 09:48:53 -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 1wSdue-00032x-MK for bitcoindev@gnusha.org; Thu, 28 May 2026 09:48:53 -0700 Received: by mail-oi1-f183.google.com with SMTP id 5614622812f47-4855237907fsf706029b6e.0 for ; Thu, 28 May 2026 09:48:52 -0700 (PDT) ARC-Seal: i=3; a=rsa-sha256; t=1779986926; cv=pass; d=google.com; s=arc-20240605; b=b+Ly9vGPRWQDqll2vZn7jB8FBLdbXze4reXAvmoqdqSFV0IvxhvHrUlYSntm0DWWAU hmqyr9VD4fw5cNFOHsp501Oy9jiLqeisXTsgYbWjKDbdVPFyDLVke2flzrLqhJ13l9FE jgO24lUGopMT9Yu/UXgTyvVy1mMRX+nujWy+Xz2EILqh/csD5AhzzAaJTZPBf+69971E m4/qA3uDE9l4S67UM43mupy6FrxyT6P7JG/o9G3Ps/ay3QBenGsTUXvVOCEGFFVu+W00 BXlVaWrLoPERv4RCE8csd8FV5gUsdOhrgcUMj2vKIHIHYsk7B1RHYo2J6jhjdna8I7wF NP/g== ARC-Message-Signature: i=3; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=mIj7rJsJknHBfL2tpGY9OmyVA5bEsdv9XXRsRVk0XOc=; fh=8028IaELwMqmE/P6oT6HHCby/0BCoyR/1sJMisgTH1I=; b=ADPMyy/7dXaapBx/KPksjN9lojzDu2kRtGMVWNG6kbQhl2tbYYRpsHwtoqFoioB/7V pCpFYBHr0vahDnwrnGIMgcU1nifPgutbbYXKnmZC0MOhVKAN1GehlSHKUz3xMxVWfJnw WC2odgYbtBBi7N1tPlKtelqsS0Z7zRPbLTBt4f88h59MN9HnrYZKFD56uSronjz1cCyS Ae01OuoDI8HnA069sNMLJm4xk/NuRJLsjzHpVvn0nodsD0kep+AmQGm0zqpUNFvowmsM 1iHOXVY3zOAxFHlTBZ1vaOfkUOB/S6Ys/lpuTMb40/SKcGHRDTgCcVawDg39DQ2LqGHV Ns1A==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=kk8pRBwS; arc=pass (i=1); spf=pass (google.com: domain of joshsdoman@gmail.com designates 2607:f8b0:4864:20::112e as permitted sender) smtp.mailfrom=joshsdoman@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1779986926; x=1780591726; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=mIj7rJsJknHBfL2tpGY9OmyVA5bEsdv9XXRsRVk0XOc=; b=QeIqaU+wOUSr8opObqHJp81Rd1Sj70ICVh9sf2zi2UlOrZVDm7GOWUwyZQdGx/K1HV nk4sp8ecc8wn3GOwhAneYEZVU3xcNftRhQ0PTpaWrWQwB6RyGbUnpMH81nVY6rpJGF6J sb2R7JWYXqGvNNVNALYqStyqO0tta2SuSY2aCMS9ocpaPQJ/EWeL3bVvo2xqmfoXOsv9 LOMkN1sdNNDq8lOlQSdRz4tNeZbpGr0ruqK7ta78LL4PJsq/pUgi2hQoo6m/+vHknarS fCxxI+BiHfeQpaop1pIXZCbhZNQ0VpjAzpfMb6kI/Y45CkRolElWLdT110MUSGTM1ANx 2bXw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779986926; x=1780591726; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=mIj7rJsJknHBfL2tpGY9OmyVA5bEsdv9XXRsRVk0XOc=; b=fuFzaF7rivE/NjAmLvE6WvoHFUAN0lfvQ7whcW3K1X3O7gUl8qBppje+FpqIgsnYJI 8bn01mpXuVsY43bexNnhkAjG29MjvXdR8B8v+4AbRJGIqVWTN5rVAruvX0wcEPR9Lb9d llaYqwIVHVBMpgPss29izrFk4w4zkQLY9t6FAExveKEWhGrxQzOWjBNvOf3GLjcqH5v4 DvQf3n8Gk4MycjzRI5aNTjGpmYBMenfslaM4l+OjfgPsKRAj9cL2X/9rAfQO6DW8UsVd Lrx0MkDGlwdkeO3ZylbzKjs9DNB/WkVyDJXvZnEkYDav+wU+rkK/vb+3DMjBhh9hV8KT elBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779986926; x=1780591726; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=mIj7rJsJknHBfL2tpGY9OmyVA5bEsdv9XXRsRVk0XOc=; b=KQDOEVJwe1ld11hgSqTF4WRhK5Cxv/ToKtNfxWm4YNgp0oJiEA4eF+harzPl04A8wo 0AsZSIbVrWKKaqdMP0wEoaycCN3cjc9c4eFn4e5pfFwfxwR5s8T3tRjxhsgo46kJTgY3 QDJCwnO+jBlUZrZMbicLRZFNT0+uPVM/M9BNUaJhHAkqBpkdoT0UHzRii01OuUYuG9yG IM4rLaVMESZkwfmLg3KtuSQD0lkFCN78vzRfzbBv4DgpWnhKwYqr/ALQl5SWCST6chnj u6ZjDRW+b2C7E5pboC2l7jHDWadUjFlmqXma/6KNuGV6KH0cb+sGHA9Z88dvHZcXaRLz RRog== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AFNElJ91Ef+Z1Ro72JRRLr9l5lFMoED/IXhaGHygM7a/5ioX45ixLEIbrVKNCl4N+nZsXAAz/RqcxwOZXnlH@gnusha.org X-Gm-Message-State: AOJu0YxzvaE5ri9Rmx23M6DBm/Uocy3qV1BWQa4MNBldCbnFUKEj50Fp qZcASTl/ZAIc7M4kHRv6lbDH4AgYsG+WDmq/sflExyn1r+CePDTkXw11 X-Received: by 2002:a05:6808:c050:b0:485:7c5a:63c3 with SMTP id 5614622812f47-4857c5a6a19mr9494389b6e.20.1779986926389; Thu, 28 May 2026 09:48:46 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMOb63ZDiQO1D4eNIxHs5t6JSL1A2UQlaNCH633/XvudjQ==" Received: by 2002:a05:6870:80ce:b0:43b:7f1f:9ce4 with SMTP id 586e51a60fabf-43c51b27b9cls817620fac.1.-pod-prod-01-us; Thu, 28 May 2026 09:48:39 -0700 (PDT) X-Received: by 2002:a05:6808:640f:b0:485:42f0:7eb9 with SMTP id 5614622812f47-48549d6bb9dmr16881831b6e.5.1779986919523; Thu, 28 May 2026 09:48:39 -0700 (PDT) Received: by 2002:a05:6808:4a50:10b0:479:9f23:6621 with SMTP id 5614622812f47-485cdba3704msb6e; Thu, 28 May 2026 09:38:25 -0700 (PDT) X-Received: by 2002:a05:6808:3086:b0:479:db65:8dbc with SMTP id 5614622812f47-4854a24dcdfmr16752233b6e.30.1779986304769; Thu, 28 May 2026 09:38:24 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1779986304; cv=pass; d=google.com; s=arc-20240605; b=UECKKYyJ9b/qHlBCCPrHYycZGhjngkFgdyeaNq/4xwro26OhsGuBBYnGA9/1X0Bii1 O5cIXNMlItk2W228WZ0N87BwK+YWiTfZNBTnl4ej222nKmNrhe6AlIxL+OhtBYCtUz9D kxBH8aMtiYQtnUNA0Y/k/Wa5nzvczOcauC9nHNdEocdboFdzWXqp0t5aHdGOLExW8WfV QFKYiK2BKDrVBqzR5P8ub0+2KyGLdSIyKr/3NJY8ue6RIyZQNE0LuTEKSNVKjorP3aCz Zx8wNAfql8uTmOE9fWEpn3kLcUk8J7Kj5MeXqsh2d86iCju1d/DLWHqb35BlHJGjgiGg 310Q== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=753vyM9WCXTfgIEJsNy8+2z+CDGQCulvgy8DaqDeStU=; fh=sjkP8zjFS5lFlY+fNUHD47XPXx06dShKmNgWs4F+if8=; b=FrWJh70W6CInFxYICNYZyAUU+UxWTu2tZuztEFuymDdOJXGZmcEvCt/52qTMCnc+qO vr16feexacKdQhJSG5LD3ayCqwyQycpC15ZwJ3iOHtaR6wV72sf064eZQwCHcczan9DC 9iaU6nHl0gVnL2qTVCEhkj2IeCJSCG3GsJEAUk+ygIBZ2BHcusIW96mnX6/nBiTRXnzF puyNm6KSTfElao+O7YseVe6O1M7i45OMzHzZhD4RjWhkUYQIm3pHBqBD0xBnlI6haSvW S/Av1Wzo/fBmuCN36aRDGjbEvCFNRttGtl8S3KS6l2jgv64eNbkSnp7scFm1DXFhrEOa UrfQ==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=kk8pRBwS; arc=pass (i=1); spf=pass (google.com: domain of joshsdoman@gmail.com designates 2607:f8b0:4864:20::112e as permitted sender) smtp.mailfrom=joshsdoman@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-yw1-x112e.google.com (mail-yw1-x112e.google.com. [2607:f8b0:4864:20::112e]) by gmr-mx.google.com with ESMTPS id 46e09a7af769-7e606587245si615414a34.4.2026.05.28.09.38.24 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 28 May 2026 09:38:24 -0700 (PDT) Received-SPF: pass (google.com: domain of joshsdoman@gmail.com designates 2607:f8b0:4864:20::112e as permitted sender) client-ip=2607:f8b0:4864:20::112e; Received: by mail-yw1-x112e.google.com with SMTP id 00721157ae682-7dca5a81be2so9204287b3.2 for ; Thu, 28 May 2026 09:38:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1779986304; cv=none; d=google.com; s=arc-20240605; b=gHFyoUvZL3p+4wAZ/jdH9+jqN5qkEqIL1H46WECEjOhB7Ihf/tEnjBq+lO0FfUai6G DzPmkom2HOuvDdDipLTvH+d0StHMScJM6d8XVcE6frHqrSaiBKVQ5VWaEzhYFVOtUu6Q MzYxcgIg4Rt+dih83FZxUc0miaa36PEsAeWQdDQ7rNYmpObv77cirhGEIOYJmZMQVAJq dN1Wo3kWPgYOWAqzTAe1oCZX/Bwn4RVSQ/lkXYwt/+1vDdo/JOJ96RiUu4ItC2CTRC6t xjitZCjyrCM90reiGz0wVd21DLTf1oElv7FSCavhe4MB06DEg5tHiUNoHZ2Ur7m55eaV /bQA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=753vyM9WCXTfgIEJsNy8+2z+CDGQCulvgy8DaqDeStU=; fh=sjkP8zjFS5lFlY+fNUHD47XPXx06dShKmNgWs4F+if8=; b=cl3kA5xHoBdLPyjwcZgXTfD2EigOPjB7bo0us5+eyQopAIAPdRvQWJjmnhGYd/FOh1 /tZXPNPJLTGDJ96S4ZsfHaV+SwfKgW2FtT/Ues1ryC5/+tjZYmfUToJc5l6oHepCPIVU J5cH37bFVSv1o5ci2sHe0DLPqSRXgvDFYXCN9FyGh6rQQG1AL4xA0DANKPXy5dCB+4aE 7iDRatnoIteuphhNhlLq3eJX1iKSI3IatfojPFBQn6xW3/pqQKn9Lh2ZfLZDO5Sj9iLi wiBKqAtvn8IusUj9/OJrOceb9E00d6xCUgh9qxWME/l5Ww3DhjxY90w7+YLGjvO707F5 h1rQ==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Gm-Gg: Acq92OGx0oZLel9Na6qcYlQxtDqUQ5g2m5NLGRI2OfEPhR7fsB3+r1lXTyf2n45hSAx zKousRIV4KUjghpHtX75lVH0dirQa+3So8PcZpWU45NULNXFhz3uj98ESOaNom8HIyQM8WrFqdA RXVoGQoDMdV/JsJGjTnQqCcuQnaX/FvlIoan3PsEtV7hP70ljUz8huaQ94CGHNp8ZIfKsXrAKUb +XtNEpVIwQN6rnngy5fzpDkNSeqJn9lxyweKY1HGkmSQRql3uoFpi+BtMBi9s76kDM4XGYhm+EL /MfPw2W6aZ4vf0M= X-Received: by 2002:a05:690c:25c9:b0:7bd:6a98:58db with SMTP id 00721157ae682-7d338b81c4dmr298382397b3.22.1779986304011; Thu, 28 May 2026 09:38:24 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Josh Doman Date: Thu, 28 May 2026 12:38:12 -0400 X-Gm-Features: AVHnY4LFw8Pldkor9FJupMIviSl9tT6B0asZHuCFslsGVwtbM6Y7_CWTqWLllKY Message-ID: Subject: Re: [bitcoindev] Re: Mapping the design space of sibling-aware covenants To: Greg Sanders Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="0000000000005b12b30652e35b4e" X-Original-Sender: joshsdoman@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=kk8pRBwS; arc=pass (i=1); spf=pass (google.com: domain of joshsdoman@gmail.com designates 2607:f8b0:4864:20::112e as permitted sender) smtp.mailfrom=joshsdoman@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.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 (/) --0000000000005b12b30652e35b4e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > 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=E2=80=AFAM Greg Sanders 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=E2=80=AFPM 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 *can= not >> 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, an= d >> 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. CL= RT >> 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 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-eeb1= be02c510n%40googlegroups.com > > . > --=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/= CAB3%3D21nrvi-XyiXom9aNvVe9Ri59ugjj%3D_WG2wgYMWiGaFQxjA%40mail.gmail.com. --0000000000005b12b30652e35b4e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Can you remind me in what way A= rk would benefit from sibling commitments?=C2=A0

I= n all honesty, sibling commitments have minimal benefit to Ark, so in retro= spect, it is not a great example.

The only place s= ibling commitments could theoretically benefit Ark is by reducing the cost = of spending a connector output, since each connector output is created in a= dvance to be spent by a specific forfeit transaction (for an on-chain withd= rawal).

Realizing the cost savings, though, would = require an explicit Pay-to-Bare-Tapscript or Pay-to-TemplateHash witness pr= ogram, 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 creat= e a hash cycle.

<= div dir=3D"ltr" class=3D"gmail_attr">On Thu, May 28, 2026 at 10:14=E2=80=AF= AM Greg Sanders <gsanders87@gmai= l.com> wrote:
> Ark

= Can you remind me in what way Ark would benefit 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 = others, I'm interested in the OP_CTV and OP_TEMPLATEHASH proposals. One= subtle difference is that OP_TEMPLATEHASH does not enable sibling-aware co= venants, like those used in BitVM, Ark, and (potentially) LN-Symmetry.[1] T= his requires a connector output and a sibling prevout commitment. This way,= additional conditions can be added to the covenant, or it can be invalidat= ed altogether.

Personally, I find unsatisfactory the met= hod 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 requ= ires 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 helpf= ul 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 scriptSig= s.
2.=C2=A0Dynamic MuHash: precompute a MuHash co= mmitment to all indexed prevouts and then remove the prevout at the current= index.
3.=C2=A0All-but-first: restrict executi= on to the first input and commit to all other prevouts.
4.= =C2=A0First-only: commit to the prevout at the first index, if the c= urrent index is non-zero.
5.=C2=A0Next-only: commit to the= prevout at the next index, if present.

An a= lternative approach is to create a new witness program, which indirectly en= forces a sibling prevout commitment:
6.=C2=A0=C2=A0Pay-to-Prev= out-Anchor (P2PA):=C2=A0an anyone-can-spend output that=C2=A0cannot = be created=C2=A0unless the output's program is the hash of the prev= out at the same index in that transaction.

The fin= al 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 sc= ript.

I won't go into the pros and cons of eac= h option, except to say that I think Option 5 strikes a nice balance betwee= n minimalism, pragmatism, and flexibility.[2]

Most= ly, I wanted to list what options I think exist. If I missed any, please le= t me know!

Best,
Josh

[1] Eliminating the 2x-delay problem in LN-Symmetry requires a co= ntract-level relative=C2=A0timelock (CLRT) and a sibling-aware covenant. CL= RT capabilities remain an active area of research and may not exist in the = first iteration of LN-Symmetry.

See:= =C2=A0https://delvingbitcoin.org/t/contract-level-relative-t= imelocks-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 commo= n single-input use case.
- Solves for the two-input siblin= g-aware covenant common to L2 protocols.
- Leaves the door= open to multi-input covenants with no sibling commitments.
<= i>- Requires no additional pre-computation.

--
You received this message because you are subscribed to a topic in the Goog= le Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this topic, visit https://group= s.google.com/d/topic/bitcoindev/uyRpzE6IFOQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bitco= indev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.googl= e.com/d/msgid/bitcoindev/c00f0fdf-950b-4ff8-a502-eeb1be02c510n%40googlegrou= ps.com.

--
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/bitcoindev/CAB3%3D21nrvi-XyiXom9aNvVe9Ri59ugjj%3D_WG2wgYMWiGaFQxjA%= 40mail.gmail.com.
--0000000000005b12b30652e35b4e--