From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 To: Bitcoin Development Mailing List Message-Id: In-Reply-To: <4TrCdBvommfJvrK94SqEmNb_pBwsF8dW1n2dY3MYX_z0IMmy4bXoMkrhQ3SBdSnWA6gYMkCgssjzLmH0iauwKuoh_9T4_kLrs_Q5knYPXG0=@protonmail.com> References: <8a9a2299-ab4b-45a4-8b9d-95798e6bb62a@mattcorallo.com> <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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , 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 > > > > On Thursday, July 3rd, 2025 at 4:54 AM, Anthony Towns =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.

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.

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

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.

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

Th= oughts?

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 sug= gests inspection of other inputs can be useful for applications
leveraging connector outputs.

While it is potentially compelling, the BitVM use case was only briefly= presented, with no
demonstration or even detailed description of how it would work in prac= tice. This makes it hard to
assess the costs and benefits of this approach. Furthermore, it's h= ard to assess how much of an
improvement it brings to Bitcoin users as BitVM has yet to be delivered= and see any meaningful
adoption.

As Greg responded when it was raised earlier in this thread[^0], as thi= ngs stand today i don't think
this idea justifies the leap in expressivity.

Best,
Antoine

[^0]: https://gnusha.org/pi/bitcoindev/8d37b779-bf2e-4f63...@googlegro= ups.com


On Thursday, July 3rd, 2025 at 4:54 AM, Anthony Towns <a...@erisian.com.au> wrote:

>=20
>=20
> On Tue, Jun 24, 2025 at 11:54:02AM -0400, Matt Corallo wrote:
>=20
> > > which
> > > warrants a compelling demonstration that arbitrary trans= action introspection
> > > does enable important use cases not achievable with more= minimal capabilities.
> > > I'm somewhat skeptical that showing this isn't r= ather simple,
>=20
>=20
> I think the BitVM/CTV idea posted on delving [0] is one such simpl= e demo?
>=20
> I gave an example in that thread of how you'd implement the de= sired
> construct using bllsh's introspection primitives, but the same= could
> equally well be done with Rusty's as-yet unpublished OP_TX, so= mething
> like:
>=20
> DUP 0x1011 TX 0x00000002 EQUALVERIFY 0x1009 TX 0x0809 TX EQUALVERI= FY
>=20
> where:
>=20
> * "0x1011 TX" pops an input index from the stack and giv= es the four-byte
> vout index of that input's prevout
> * "0x1009 TX" pops an input index from the stack and giv= es the txid of 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 sibling
> output at index 2 is also being spent in the same transaction"= ;)
>=20
> Cheers,
> aj
>=20
> [0] https://delvingbitcoin= .org/t/how-ctv-csfs-improves-bitvm-bridges/1591
>=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 email to bitcoindev+...@= googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/aGX_MN= ORQVQT_lp4%40erisian.com.au.

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