path: root/d1/68227bd90003634e9128181d87efea205537d9

Delivery-date: Wed, 09 Jul 2025 14:54:06 -0700
Received: from mail-oo1-f59.google.com ([209.85.161.59])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDDJX3VKZACRB46JXPBQMGQESGJR7LY@googlegroups.com>)
	id 1uZcjt-0008RI-BV
	for bitcoindev@gnusha.org; Wed, 09 Jul 2025 14:54:05 -0700
Received: by mail-oo1-f59.google.com with SMTP id 006d021491bc7-60be0456405sf101626eaf.2
        for <bitcoindev@gnusha.org>; Wed, 09 Jul 2025 14:54:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1752098039; x=1752702839; 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=PGXnBe1JUITfSCwZ8iwFLx+sM6UZpXMzGkjd+PYrmVA=;
        b=qxYPJKlVVld/ioi7HyfwUXKN1TTzL5EZ3l7u/1yJroOfWWFMKiXWXpVDs1PMWlsjWB
         CAKJYhqREaFre2RcDHcXHiZ2TkcIQVGUR5mv6fRq44Hf9oBTVyYjHfhteU7zWtYnaCKu
         oV3aIVaJQddGTLluWrPt3/ruQuED9ZAMGSZvKwq/dAFM0BYoDo28YAzRRS70KXThpfVg
         bu/eLjaXSuan/Oebo6xiObewDWJkN0f0h69Rne8Pzwxgh/mycaU6o4PlG5QPfFmW43Uw
         F96CAcIl5NHvz2qjT3Fn/KtRCdtK4pnE39DW3q9OYWXVcDmxn4QzpDnfVXcc7XZ5JUMj
         P8Xw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1752098039; x=1752702839; 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=PGXnBe1JUITfSCwZ8iwFLx+sM6UZpXMzGkjd+PYrmVA=;
        b=k5oPImBneKZWFyUW49FBMQltWiXMOqK4BpgVYYZ4ejBrjGkj1uLkdbiRUlTxOYKlN1
         iWmM+xvF2p6oj+Uqn2cjFhTqlROPyTPP9wN2kHDmAYDX8UCpiVfpn9m+OO0GXC9EMsjx
         +3CLEJiE+8juhmzoX7tjN0IWkvae84d42QLIqGLv0n4E+cvuEsyM74KqNBAPd10dieEd
         k8dTWjBSfKeYqnSewRQMX+Jsq4LIMTKeh5H+xnj2ItFE4d3DrMFPS8Fylyjyh9D+Bbgf
         bYQ6nWvVKt2imhNjxZ7WVDggMch71+TQ36xED1YElYI5N5o9LNXPsDCesM70Y+UOHRmz
         RYsw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1752098039; x=1752702839;
        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=PGXnBe1JUITfSCwZ8iwFLx+sM6UZpXMzGkjd+PYrmVA=;
        b=qr4uzcKZ/Q8vF7yK+WpDNMMC84/0p2z8Rn6C/AqB2OJBgf3fOIDgvN5Uu+O/ivnCyd
         2HG+W4tgHkgax+mroRmrTRT5LwfxCuwPUZpTpv5UTL4ZwZOKZHITksoKils14Z9GuOGE
         uy3NEXowXdRqVP2E9iqIot4Vm5Xg47HwMpSUBKiPdSXBufeG0FjR1WXjG5LDJYUfQD10
         tkybAlJ8i9Vzl5/inlwMwQa8vzoVB6/vvSllJ5cYGMEQHY6LpDCAs3zUIiiQ265fEfDp
         zHOcRkhE9eR0/pvNeGwrCzPAGVbt/sU/WVVmipSfh1pfqNk5bkfvlHDWwNuLfHHyvmF7
         DoJw==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCWbmzRsIfFN8tpjWG+ESRG57fQOYl60oOZZ1VKJrhKNJZZzOFQqz2f1Q2YkE1if5k4+1jXb06GPlsTG@gnusha.org
X-Gm-Message-State: AOJu0YyDganC2IakE9woR5dRKLe4XXCQSGc66FsPhaVBb7R9OonMzsdS
	KgPOF+K73gl2p2IslzaKb8dVaf7eKUD9S83pJgNR9hitqDdmq7+3FBkS
X-Google-Smtp-Source: AGHT+IFYY6z5wq+c3/NsEUgj2mu5UXfUe8zUl10RGv/gL9YqK5aU7N9Mwa2xW6ouKwa1wgStUg1VDA==
X-Received: by 2002:a05:6870:e80a:b0:2d8:957a:5176 with SMTP id 586e51a60fabf-2ff107c2681mr245111fac.5.1752098039306;
        Wed, 09 Jul 2025 14:53:59 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZeOow0y01xDDmuc4OLY5R7Uf1pHZVn5jM5zJS0dDMRPVA==
Received: by 2002:a05:6870:b1c4:b0:2ea:7154:1841 with SMTP id
 586e51a60fabf-2ff0bd28a2fls182038fac.2.-pod-prod-03-us; Wed, 09 Jul 2025
 14:53:55 -0700 (PDT)
X-Received: by 2002:a05:6808:3023:b0:404:e2fe:ee91 with SMTP id 5614622812f47-412b9f4fe2amr3027107b6e.8.1752098035311;
        Wed, 09 Jul 2025 14:53:55 -0700 (PDT)
Received: by 2002:a05:690c:d8b:b0:710:f35d:a3b2 with SMTP id 00721157ae682-7166a91b6ffms7b3;
        Wed, 9 Jul 2025 14:30:12 -0700 (PDT)
X-Received: by 2002:a05:690c:6907:b0:712:cc11:af8 with SMTP id 00721157ae682-717b19c1bf6mr63636607b3.27.1752096610686;
        Wed, 09 Jul 2025 14:30:10 -0700 (PDT)
Date: Wed, 9 Jul 2025 14:30:10 -0700 (PDT)
From: Josh Doman <joshsdoman@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <b72e6f6f-af27-4043-b714-4e607bbe8880n@googlegroups.com>
In-Reply-To: <4TrCdBvommfJvrK94SqEmNb_pBwsF8dW1n2dY3MYX_z0IMmy4bXoMkrhQ3SBdSnWA6gYMkCgssjzLmH0iauwKuoh_9T4_kLrs_Q5knYPXG0=@protonmail.com>
References: <F5vsDVNGXP_hmCvp4kFnptFLBCXOoRxWk9d05kSInq_kXj0ePqVAJGADkBFJxYIGkjk8Pw1gzBonTivH6WUUb4f6mwNCmJIwdXBMrjjQ0lI=@protonmail.com>
 <8a9a2299-ab4b-45a4-8b9d-95798e6bb62a@mattcorallo.com>
 <aGX_MNORQVQT_lp4@erisian.com.au>
 <4TrCdBvommfJvrK94SqEmNb_pBwsF8dW1n2dY3MYX_z0IMmy4bXoMkrhQ3SBdSnWA6gYMkCgssjzLmH0iauwKuoh_9T4_kLrs_Q5knYPXG0=@protonmail.com>
Subject: Re: [bitcoindev] What's a good stopping point? Making the case for
 the capabilities enabled by CTV+CSFS
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_11610_1810237292.1752096610423"
X-Original-Sender: joshsdoman@gmail.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)

------=_Part_11610_1810237292.1752096610423
Content-Type: multipart/alternative; 
	boundary="----=_Part_11611_660666791.1752096610423"

------=_Part_11611_660666791.1752096610423
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I tend to agree. It's hard to justify the leap in expressivity of OP_TX /=
=20
OP_TXHASH solely on the basis of enabling commitments to sibling prevouts.=
=20
A more targeted approach would be better.

In that vein, I think there's a way to use MuHash to generalize CTV /=20
TEMPLATEHASH and commit to sibling prevouts in constant time.

The idea is to precompute a MuHash accumulator containing SHA256(index ||=
=20
prevout) for each input in the transaction.

Then, to compute the sibling commitment for input i, we simply copy the=20
accumulator and remove the SHA256 hash for that input. Thanks to MuHash,=20
this takes constant time. Finally, we include the sibling commitment in the=
=20
existing proposed commitment scheme.

This would represent a low-cost way to commit to the next txid, providing=
=20
predictability regardless of how many inputs are spent (unlike existing=20
proposals). Given that MuHash is already in the codebase, I'm inclined to=
=20
believe this wouldn't be a heavy lift and would better achieve the goal of=
=20
a primitive that "commits to the next transaction."

Thoughts?

Best,
Josh

On Friday, July 4, 2025 at 9:08:48=E2=80=AFAM UTC-4 Antoine Poinsot wrote:

> I agree the BitVM/CTV idea suggests inspection of other inputs can be=20
> useful for applications
> leveraging connector outputs.
>
> While it is potentially compelling, the BitVM use case was only briefly=
=20
> presented, with no
> demonstration or even detailed description of how it would work in=20
> practice. This makes it hard to
> assess the costs and benefits of this approach. Furthermore, it's hard to=
=20
> assess how much of an
> improvement it brings to Bitcoin users as BitVM has yet to be delivered=
=20
> and see any meaningful
> adoption.
>
> As Greg responded when it was raised earlier in this thread[^0], as thing=
s=20
> stand today i don't think
> this idea justifies the leap in expressivity.
>
> Best,
> Antoine
>
> [^0]:=20
> https://gnusha.org/pi/bitcoindev/8d37b779-bf2e-4f63...@googlegroups.com=
=20
> <https://gnusha.org/pi/bitcoindev/8d37b779-bf2e-4f63-a51c-9953434d7553n@g=
ooglegroups.com>
>
>
> On Thursday, July 3rd, 2025 at 4:54 AM, Anthony Towns <a...@erisian.com.a=
u>=20
> wrote:
>
> >=20
> >=20
> > On Tue, Jun 24, 2025 at 11:54:02AM -0400, Matt Corallo wrote:
> >=20
> > > > which
> > > > warrants a compelling demonstration that arbitrary transaction=20
> introspection
> > > > does enable important use cases not achievable with more minimal=20
> capabilities.
> > > > I'm somewhat skeptical that showing this isn't rather simple,
> >=20
> >=20
> > I think the BitVM/CTV idea posted on delving [0] is one such simple dem=
o?
> >=20
> > I gave an example in that thread of how you'd implement the desired
> > construct using bllsh's introspection primitives, but the same could
> > equally well be done with Rusty's as-yet unpublished OP_TX, something
> > like:
> >=20
> > DUP 0x1011 TX 0x00000002 EQUALVERIFY 0x1009 TX 0x0809 TX EQUALVERIFY
> >=20
> > where:
> >=20
> > * "0x1011 TX" pops an input index from the stack and gives the four-byt=
e
> > vout index of that input's prevout
> > * "0x1009 TX" pops an input index from the stack and gives the txid of=
=20
> that input's
> > prevout
> > * "0x0809 TX" gives the txid of the current input's prevout
> >=20
> > (this encodes "this utxo can only be spent (via this path) if its sibli=
ng
> > output at index 2 is also being spent in the same transaction")
> >=20
> > Cheers,
> > aj
> >=20
> > [0]=20
> https://delvingbitcoin.org/t/how-ctv-csfs-improves-bitvm-bridges/1591
> >=20
> > --
> > You received this message because you are subscribed to the Google=20
> Groups "Bitcoin Development Mailing List" group.
> > To unsubscribe from this group and stop receiving emails from it, send=
=20
> an email to bitcoindev+...@googlegroups.com.
> > To view this discussion visit=20
> https://groups.google.com/d/msgid/bitcoindev/aGX_MNORQVQT_lp4%40erisian.c=
om.au
> .
>

--=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/=
b72e6f6f-af27-4043-b714-4e607bbe8880n%40googlegroups.com.

------=_Part_11611_660666791.1752096610423
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I tend to agree. It's hard to justify the leap in expressivity of OP_TX / O=
P_TXHASH solely on the basis of enabling commitments to sibling prevouts. A=
 more targeted approach would be better.<div><br /></div><div>In that vein,=
 I think there's a way to use MuHash to generalize CTV / TEMPLATEHASH and c=
ommit to sibling prevouts in constant time.<br /><div><br /></div><div><div=
>The idea is to precompute a MuHash accumulator containing SHA256(index || =
prevout) for each input in the transaction.<br /></div><div><br /></div><di=
v>Then, to compute the sibling commitment for input i, we simply copy the a=
ccumulator and remove the SHA256 hash for that input. Thanks to MuHash, thi=
s takes constant time. Finally, we include the sibling commitment in the ex=
isting proposed commitment scheme.</div><div><br /></div></div></div><div>T=
his would represent a low-cost way to commit to the next txid, providing pr=
edictability regardless of how many inputs are spent (unlike existing propo=
sals). Given that MuHash is already in the codebase, I'm inclined to believ=
e this wouldn't be a heavy lift and would better achieve the goal of a prim=
itive that "commits to the next transaction."</div><div><br /></div><div>Th=
oughts?</div><div><br /></div><div>Best,</div><div>Josh</div><br /><div cla=
ss=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">On Friday, July 4=
, 2025 at 9:08:48=E2=80=AFAM UTC-4 Antoine Poinsot wrote:<br/></div><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0 0 0 0.8ex; border-left: 1px s=
olid rgb(204, 204, 204); padding-left: 1ex;">I agree the BitVM/CTV idea sug=
gests inspection of other inputs can be useful for applications
<br>leveraging connector outputs.
<br>
<br>While it is potentially compelling, the BitVM use case was only briefly=
 presented, with no
<br>demonstration or even detailed description of how it would work in prac=
tice. This makes it hard to
<br>assess the costs and benefits of this approach. Furthermore, it&#39;s h=
ard to assess how much of an
<br>improvement it brings to Bitcoin users as BitVM has yet to be delivered=
 and see any meaningful
<br>adoption.
<br>
<br>As Greg responded when it was raised earlier in this thread[^0], as thi=
ngs stand today i don&#39;t think
<br>this idea justifies the leap in expressivity.
<br>
<br>Best,
<br>Antoine
<br>
<br>[^0]: <a href=3D"https://gnusha.org/pi/bitcoindev/8d37b779-bf2e-4f63-a5=
1c-9953434d7553n@googlegroups.com" target=3D"_blank" rel=3D"nofollow" data-=
saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://gnush=
a.org/pi/bitcoindev/8d37b779-bf2e-4f63-a51c-9953434d7553n@googlegroups.com&=
amp;source=3Dgmail&amp;ust=3D1752182932689000&amp;usg=3DAOvVaw3f2I6lWaaa5F-=
IukdW6x9p">https://gnusha.org/pi/bitcoindev/8d37b779-bf2e-4f63...@googlegro=
ups.com</a>
<br>
<br>
<br>On Thursday, July 3rd, 2025 at 4:54 AM, Anthony Towns &lt;<a href data-=
email-masked rel=3D"nofollow">a...@erisian.com.au</a>&gt; wrote:
<br>
<br>&gt;=20
<br>&gt;=20
<br>&gt; On Tue, Jun 24, 2025 at 11:54:02AM -0400, Matt Corallo wrote:
<br>&gt;=20
<br>&gt; &gt; &gt; which
<br>&gt; &gt; &gt; warrants a compelling demonstration that arbitrary trans=
action introspection
<br>&gt; &gt; &gt; does enable important use cases not achievable with more=
 minimal capabilities.
<br>&gt; &gt; &gt; I&#39;m somewhat skeptical that showing this isn&#39;t r=
ather simple,
<br>&gt;=20
<br>&gt;=20
<br>&gt; I think the BitVM/CTV idea posted on delving [0] is one such simpl=
e demo?
<br>&gt;=20
<br>&gt; I gave an example in that thread of how you&#39;d implement the de=
sired
<br>&gt; construct using bllsh&#39;s introspection primitives, but the same=
 could
<br>&gt; equally well be done with Rusty&#39;s as-yet unpublished OP_TX, so=
mething
<br>&gt; like:
<br>&gt;=20
<br>&gt; DUP 0x1011 TX 0x00000002 EQUALVERIFY 0x1009 TX 0x0809 TX EQUALVERI=
FY
<br>&gt;=20
<br>&gt; where:
<br>&gt;=20
<br>&gt; * &quot;0x1011 TX&quot; pops an input index from the stack and giv=
es the four-byte
<br>&gt; vout index of that input&#39;s prevout
<br>&gt; * &quot;0x1009 TX&quot; pops an input index from the stack and giv=
es the txid of that input&#39;s
<br>&gt; prevout
<br>&gt; * &quot;0x0809 TX&quot; gives the txid of the current input&#39;s =
prevout
<br>&gt;=20
<br>&gt; (this encodes &quot;this utxo can only be spent (via this path) if=
 its sibling
<br>&gt; output at index 2 is also being spent in the same transaction&quot=
;)
<br>&gt;=20
<br>&gt; Cheers,
<br>&gt; aj
<br>&gt;=20
<br>&gt; [0] <a href=3D"https://delvingbitcoin.org/t/how-ctv-csfs-improves-=
bitvm-bridges/1591" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=
=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://delvingbitcoin.org/t=
/how-ctv-csfs-improves-bitvm-bridges/1591&amp;source=3Dgmail&amp;ust=3D1752=
182932689000&amp;usg=3DAOvVaw3JYYqgNVmSU1Ln3tQ7jAp8">https://delvingbitcoin=
.org/t/how-ctv-csfs-improves-bitvm-bridges/1591</a>
<br>&gt;=20
<br>&gt; --
<br>&gt; You received this message because you are subscribed to the Google=
 Groups &quot;Bitcoin Development Mailing List&quot; group.
<br>&gt; To unsubscribe from this group and stop receiving emails from it, =
send an email to <a href data-email-masked rel=3D"nofollow">bitcoindev+...@=
googlegroups.com</a>.
<br>&gt; To view this discussion visit <a href=3D"https://groups.google.com=
/d/msgid/bitcoindev/aGX_MNORQVQT_lp4%40erisian.com.au" target=3D"_blank" re=
l=3D"nofollow" data-saferedirecturl=3D"https://www.google.com/url?hl=3Den&a=
mp;q=3Dhttps://groups.google.com/d/msgid/bitcoindev/aGX_MNORQVQT_lp4%2540er=
isian.com.au&amp;source=3Dgmail&amp;ust=3D1752182932689000&amp;usg=3DAOvVaw=
36AKZ_sa7jn0fhNZnyD6n8">https://groups.google.com/d/msgid/bitcoindev/aGX_MN=
ORQVQT_lp4%40erisian.com.au</a>.
<br></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/b72e6f6f-af27-4043-b714-4e607bbe8880n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/b72e6f6f-af27-4043-b714-4e607bbe8880n%40googlegroups.com</a>.<br />

------=_Part_11611_660666791.1752096610423--

------=_Part_11610_1810237292.1752096610423--