From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 24 Jun 2025 08:13:05 -0700 Received: from mail-oa1-f63.google.com ([209.85.160.63]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uU5Ka-0003ew-Jr for bitcoindev@gnusha.org; Tue, 24 Jun 2025 08:13:05 -0700 Received: by mail-oa1-f63.google.com with SMTP id 586e51a60fabf-2eae95dfae3sf5056107fac.1 for ; Tue, 24 Jun 2025 08:13:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1750777978; x=1751382778; 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=45lJjyPtX+YtTItS9jG9KjOZ0cWDHhfwWpVJbyyZurc=; b=MF8VxqHNCXFuUD68pfQC8Y28maSm7lhP28nuGmb1OyO4vpp7LyudM5snnVyXA0M+yf bAyzN2DeGNKPtPJ8OgT/rW1ejqD+Gw4Jamg838/cinJxULdxKVLOcHh9WmGnmL2LmAJ5 X0X97mNzivwnGfS47xdwZhKH6C89owTqyFsYo92w9zl/4d/DEn+LyP2FjhVprz5IIbMZ 8gfFkAaL5hIakmrL/UDNUbD9SYtFkLa/9j/lLXXRlPjG81mm3W6A/kkQQLvxvKTIsFLj eKiLqRAUGAtH8kCkEOBV1uHJDMpAYyGYwAHvGa3nOEH9ZvJTMcx4r5mLwnpPE2y30u+P DaWg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1750777978; x=1751382778; 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=45lJjyPtX+YtTItS9jG9KjOZ0cWDHhfwWpVJbyyZurc=; b=Wedb+lBkY+baxEPytdC14srS6lw0SBchSjxqoO3LFfkdOij07ARErIgpaWDSrqINE+ 6jlp9/74QUa2E+tRes/jeRD5jW5DlJxSzsJNaK6LX/2t5WbFr8AgrDxX704Y/k3LRWri wJvAYnuOLxeu/pyWEvFclDdwrbhwU6iFfsR8UIqQ2troWbpV4Nn2vfsNKfHeMJ50+gEn m03Y3JSQPx44cIDZ/A56psbc3Z+wglrdxr0JTpAzGj6mv1kmDvq7k33pGdT78JQq6waO OedMZ9Hp9eiMtNESscieP7OoQVyRzFG6qrA9cMMAVCIYPVouD9P+/FKLKasVQgS5eO62 d/bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750777978; x=1751382778; 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=45lJjyPtX+YtTItS9jG9KjOZ0cWDHhfwWpVJbyyZurc=; b=PDVq7rxsuqHjpMMnp9b9SQOJzAHTWWQYseaBHKDVXirIMCsgGKL4YEDI1DhsutCd4n TnPHI8kKfZHQk9B4rCz8GR/xTZkzQpwF2OiEZJP7fMPlfmbjFqBrkHb8EcKxXt8Fjw60 gmkJwsbbjLaWn9z0rVSch3pePav2Ru6anUIMKt8nrkUCIf8LXOZXCyzLVFmjY8ymb73T 6dl4ifqeW6YJdxJsup87mjuInojvsCHTZp1UlihZ3eLpVa6xmNZPEZ5iUjkEN0DFhcr7 lA/KawPtMYRUSh6nAlk7jdx5svnXe5KEQCGyqICfK9VdWOKI8FryULpZ7Pl9gdw5+OU2 vRgg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCVu8WdDuuMZ9YH5ZwyDa6MW34yVqlDH/Z4DxF4vR4hM7DOA9xDw6ADduLPniSIx8fsDnOqNel811KbQ@gnusha.org X-Gm-Message-State: AOJu0YyWro7CWwuKzAfZA+7yZZaf+ZyFq+xpid4XY0m5alSQjt0Fm7Kw i78GzXMgHvVQF0pGT43BiVajk0KYtjoo9NQtDKN6ofa1lRXMJUubmBlg X-Google-Smtp-Source: AGHT+IGgdQYO7g1ikF/0lJoK/CbVOHlcTQWZEALZjA8o6JPlXtMBm61tenCtMYfYDRIdeXadQFX5DA== X-Received: by 2002:a05:6871:2b23:b0:2e9:14fe:5e71 with SMTP id 586e51a60fabf-2eeee457bd0mr11491954fac.13.1750777978377; Tue, 24 Jun 2025 08:12:58 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZcfrwsYs4g1VWZXIGImfXvfSAKwjDFgEhq3Lo1TJbxgvQ== Received: by 2002:a05:6870:63aa:b0:2c2:2e10:95dd with SMTP id 586e51a60fabf-2eba2abe6cdls3281276fac.0.-pod-prod-09-us; Tue, 24 Jun 2025 08:12:55 -0700 (PDT) X-Received: by 2002:a05:690c:4b8c:b0:714:349:583a with SMTP id 00721157ae682-71403496b77mr12532817b3.32.1750777974946; Tue, 24 Jun 2025 08:12:54 -0700 (PDT) Received: by 2002:a05:690c:340c:b0:6ef:590d:3213 with SMTP id 00721157ae682-712a53b9560ms7b3; Tue, 24 Jun 2025 07:29:28 -0700 (PDT) X-Received: by 2002:a05:690c:a86:b0:710:f39f:4d66 with SMTP id 00721157ae682-712c6383133mr238105537b3.13.1750775366944; Tue, 24 Jun 2025 07:29:26 -0700 (PDT) Date: Tue, 24 Jun 2025 07:29:25 -0700 (PDT) From: Harsha Goli To: Bitcoin Development Mailing List Message-Id: In-Reply-To: References: Subject: [bitcoindev] Re: 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_46548_1481345427.1750775365798" X-Original-Sender: harshagoli@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.2 (/) ------=_Part_46548_1481345427.1750775365798 Content-Type: multipart/alternative; boundary="----=_Part_46549_1384171008.1750775365798" ------=_Part_46549_1384171008.1750775365798 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =E2=80=8BWe will start by making the case that the capabilities "commit to = the=20 transaction spending this output" and "verify a BIP340 signature for an arbitrary message" are a good=20 stopping point for a Bitcoin soft fork. We invite anyone to share objections in reply to this thread so they can be addressed= =20 or inform a better course of action. We can consider narrower commitment combinations once we establish that=20 broad commitments are a success for bitcoin. I reject the assumption some= =20 have that narrower commitment combinations might have more market demand=20 than broader combinations, and that such assumptions might be an adequate= =20 reason to move forward with alternative proposals. Thanks, Harsha, sometimes known as arshbot On Monday, June 23, 2025 at 9:26:20=E2=80=AFAM UTC-4 Antoine Poinsot wrote: > There is excitement in the technical community about a CTV+CSFS soft fork= =20 > as specified in BIP119 and BIP348. We think > this combination of opcodes offers desirable capabilities to scale Bitcoi= n=20 > payments and is worth considering to soft > fork into Bitcoin. There has been several objections to this proposal,=20 > which we can group into three categories: > exploration of alternatives, demonstration of usage, and design of the=20 > operations to achieve these capabilities. > > In an attempt to help the proposal move forward we would like to kick-off= =20 > a discussion about the first category: > alternatives. We will start by making the case that the capabilities=20 > "commit to the transaction spending this output" > and "verify a BIP340 signature for an arbitrary message" are a good=20 > stopping point for a Bitcoin soft fork. We invite > anyone to share objections in reply to this thread so they can be=20 > addressed or inform a better course of action. > > Let's keep the discussion focused on the capabilities, not the specific= =20 > way of designing operations to achieve them. For > the sake of this discussion `OP_CTV` would be equivalent to=20 > `OP_TEMPLATEHASH` (push the template hash on the stack) as > the capability "commit to the transaction to spend an output". `OP_TXHASH= `=20 > would be separate, as a "programmable > transaction introspection" capability. > > The ability to commit to the exact transaction spending an output is=20 > useful to reduce interactivity in second-layer > protocols. For instance it can reduce roundtrips[^0] in the implementatio= n=20 > of LN-Symmetry, or make receiving an Ark > "vtxo" non-interactive[^1]. Additionally, it enables significant=20 > optimizations[^2] in the implementation of Discreet Log > Contracts. > > The ability to verify a signature for an arbitrary message in Tapscript= =20 > enables oracle attestations and a form of > delegation. Oracle attestation for instance significantly reduce[^3] the= =20 > onchain footprint of BitVM. Reducing an > application's onchain footprint benefits all Bitcoin users by easing bloc= k=20 > space competition, and it's especially > important for applications that generate very large transactions, which= =20 > could otherwise increase pressure toward mining > centralization[^4]. > > Together, these two features enable a third capability: rebindable=20 > transaction signatures. Rebindable signatures make > possible a new type of payment channels, LN-Symmetry ("Eltoo"), whose=20 > simplicity makes practical advanced constructs > such as multiparty channels. They also enable further interactivity=20 > reduction in second layer protocols, as illustrated > by the Ark variant "Erk"[^5] or the dramatic simplification[^6] they brin= g=20 > to upgrading today's Lightning (i.e. without > switching to LN-Symmetry) from HTLCs to PTLCs. > > These capabilities are simple and modular. They are well understood and= =20 > present a low risk of enabling unwanted > behaviour. They do not increase the cost of validation, have low=20 > implementation complexity and are unlikely to become > redundant, even if more powerful capabilities are added in the future.=20 > These capabilities improve existing > tried-and-proven protocols used daily by Bitcoin users, like the Lightnin= g=20 > Network. They also make new ones possible > either at all or through realistic interactivity requirements. The new=20 > enabled protocols take a similar approach to > existing Bitcoin scaling solutions, only with different tradeoffs not=20 > previously available. We can therefore reasonably > expect they won't introduce new systemic incentives, while broadening the= =20 > range of supported use cases. > > The first alternative approach to address is doing nothing. Doing nothing= =20 > is *the* valid schelling point in a system > where consensus changes must be agreed on by a supermajority of the=20 > economic activity, and ideally by all stakeholders > in the system. Unless there is a critical vulnerability being fixed, the= =20 > onus is on the proposer to overcome the various > valid objections. Further, a number of smart contracts have been deployed= =20 > on Bitcoin and more are incoming, with or > without consensus changes. No softforks on the horizon are known to=20 > generate asymptotic scaling, and what's more, > on-chain demand has not been high except on infrequent intervals. > > As said prior, we believe the capabilities of CTV+CSFS reach an=20 > appropriate bar for consideration for activation. While > it will not achieve asymptotic scaling, it will enable significant=20 > reduction in complexity in already-deployed systems, > and is worth deploying for their specific benefits. Regardless, it's=20 > important to emphasize it again: the onus is on the > proposer to overcome objections. > > Other alternative approaches to scaling Bitcoin payments have been=20 > proposed such as with validation rollups[^7], enabled > by the ability to verify a zero-knowledge proof directly in Bitcoin=20 > Script. These rollups are trustless and could > effectuate a modest factor throughput increase under realistic assumption= s=20 > and transaction load. This approach, used on > altcoins but new to Bitcoin, has yet to reach consensus among the=20 > technical community and Bitcoin users more broadly. > Relative immaturity of many of the employed crypto-systems make designing= =20 > a ZKP-specific primitive a difficult task. > Further, trustless composibility with interactive protocols like LN to=20 > achieve further scaling are speculative at the > time. Nonetheless, the capabilities that enable this alternative approach= =20 > to scaling are neither exclusionary nor > redundant with those proposed here. > > It makes sense to focus first on capabilities improving the=20 > tried-and-proven approach, as the newer approach > (and the capabilities enabling it) may come with different tradeoffs. > > Yet another alternative is a set of more powerful capabilities, enabling= =20 > the use cases that "commit to next transaction" > and "verify a BIP340 signature for an arbitrary message" enable and more.= =20 > For instance replacing "commit to the exact > transaction which must spend this output" with "programmable introspectio= n=20 > on the spending transaction's fields" has > been considered. However this approach increases implementation complexit= y=20 > and broadens the risk surface[^8], which > warrants a compelling demonstration that arbitrary transaction=20 > introspection does enable important use cases not > achievable with more minimal capabilities. > > Finally, a more radical alternative is to focus efforts to make Bitcoin= =20 > smart contracts more capable with a sane > re-design of its scripting language. Similarly to the alternative of more= =20 > powerful Bitcoin Script capabilities, it > remains to be shown that more expressivity is both safe and desirable.=20 > Furthermore, it is unclear that such an > undertaking would be achievable with the (very) limited engineering=20 > resources currently allocated to extending Bitcoin > scripting capabilities. > > In conclusion, we believe the bundle of capabilities "commitment to the= =20 > transaction spending an output" and "BIP340 > signature verification of arbitrary message" to be the best direction for= =20 > Bitcoin to take. These are well-understood, > simple capabilities, substantially improving an existing well-understood= =20 > approach to scaling Bitcoin payments. This > direction does not preclude research into more advanced capabilities,=20 > though questions remain about their overall > desirability. > > Antoine Poinsot & Greg Sanders > > [^0]: https://delvingbitcoin.org/t/ln-symmetry-project-recap/359 > [^1]: https://delvingbitcoin.org/t/the-ark-case-for-ctv/1528 > [^2]:=20 > https://gnusha.org/pi/bitcoindev/CAH5Bsr2vxL3FWXnJTszMQj83...@mail.gmail.= com=20 > > [^3]:=20 > https://delvingbitcoin.org/t/how-ctv-csfs-improves-bitvm-bridges/1591 > [^4]:=20 > https://delvingbitcoin.org/t/non-confiscatory-transaction-weight-limit/17= 32/8 > [^5]:=20 > https://delvingbitcoin.org/t/evolving-the-ark-protocol-using-ctv-and-csfs= /1602 > [^6]:=20 > https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-s= tep-towards-covenants/1509/18 > [^7]: https://github.com/john-light/validity-rollups > [^8]: https://bluematt.bitcoin.ninja/2024/04/16/stop-calling-it-mev > --=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/= b98ba037-a76b-4fac-88c2-b9f9fbca87cbn%40googlegroups.com. ------=_Part_46549_1384171008.1750775365798 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=E2=80=8BWe will start by making = the case that the capabilities "commit to the transaction spending this out= put"
and "verify= a BIP340 signature for an arbitrary message" are a good stopping point for= a Bitcoin soft fork. We invite
anyone to share objections in reply to this thread so they= can be addressed or inform a better course of action.

We can consider narrower commitment co= mbinations once we establish that broad commitments are a success for bitco= in. I reject the assumption some have that narrower commitment combinations= might have more market demand than broader combinations, and that such ass= umptions might be an adequate reason to move forward with alternative propo= sals.

Thanks,
Harsha, sometimes known as arshbot

On Monday, June 23,= 2025 at 9:26:20=E2=80=AFAM UTC-4 Antoine Poinsot wrote:
There is excitement in the tech= nical community about a CTV+CSFS soft fork as specified in BIP119 and BIP34= 8. We think
this combination of opcodes offers desirable capabilities to scale Bitc= oin payments and is worth considering to soft
fork into Bitcoin. There has been several objections to this proposal, = which we can group into three categories:
exploration of alternatives, demonstration of usage, and design of the = operations to achieve these capabilities.

In an attempt to help the proposal move forward we would like to kick-o= ff a discussion about the first category:
alternatives. We will start by making the case that the capabilities &q= uot;commit to the transaction spending this output"
and "verify a BIP340 signature for an arbitrary message" are = a good stopping point for a Bitcoin soft fork. We invite
anyone to share objections in reply to this thread so they can be addre= ssed or inform a better course of action.

Let's keep the discussion focused on the capabilities, not the spec= ific way of designing operations to achieve them. For
the sake of this discussion `OP_CTV` would be equivalent to `OP_TEMPLAT= EHASH` (push the template hash on the stack) as
the capability "commit to the transaction to spend an output"= . `OP_TXHASH` would be separate, as a "programmable
transaction introspection" capability.

The ability to commit to the exact transaction spending an output is us= eful to reduce interactivity in second-layer
protocols. For instance it can reduce roundtrips[^0] in the implementat= ion of LN-Symmetry, or make receiving an Ark
"vtxo" non-interactive[^1]. Additionally, it enables signific= ant optimizations[^2] in the implementation of Discreet Log
Contracts.

The ability to verify a signature for an arbitrary message in Tapscript= enables oracle attestations and a form of
delegation. Oracle attestation for instance significantly reduce[^3] th= e onchain footprint of BitVM. Reducing an
application's onchain footprint benefits all Bitcoin users by easin= g block space competition, and it's especially
important for applications that generate very large transactions, which= could otherwise increase pressure toward mining
centralization[^4].

Together, these two features enable a third capability: rebindable tran= saction signatures. Rebindable signatures make
possible a new type of payment channels, LN-Symmetry ("Eltoo"= ), whose simplicity makes practical advanced constructs
such as multiparty channels. They also enable further interactivity red= uction in second layer protocols, as illustrated
by the Ark variant "Erk"[^5] or the dramatic simplification[^= 6] they bring to upgrading today's Lightning (i.e. without
switching to LN-Symmetry) from HTLCs to PTLCs.

These capabilities are simple and modular. They are well understood and= present a low risk of enabling unwanted
behaviour. They do not increase the cost of validation, have low implem= entation complexity and are unlikely to become
redundant, even if more powerful capabilities are added in the future. = These capabilities improve existing
tried-and-proven protocols used daily by Bitcoin users, like the Lightn= ing Network. They also make new ones possible
either at all or through realistic interactivity requirements. The new = enabled protocols take a similar approach to
existing Bitcoin scaling solutions, only with different tradeoffs not p= reviously available. We can therefore reasonably
expect they won't introduce new systemic incentives, while broadeni= ng the range of supported use cases.

The first alternative approach to address is doing nothing. Doing nothi= ng is *the* valid schelling point in a system
where consensus changes must be agreed on by a supermajority of the eco= nomic activity, and ideally by all stakeholders
in the system. Unless there is a critical vulnerability being fixed, th= e onus is on the proposer to overcome the various
valid objections. Further, a number of smart contracts have been deploy= ed on Bitcoin and more are incoming, with or
without consensus changes. No softforks on the horizon are known to gen= erate asymptotic scaling, and what's more,
on-chain demand has not been high except on infrequent intervals.

As said prior, we believe the capabilities of CTV+CSFS reach an appropr= iate bar for consideration for activation. While
it will not achieve asymptotic scaling, it will enable significant redu= ction in complexity in already-deployed systems,
and is worth deploying for their specific benefits. Regardless, it'= s important to emphasize it again: the onus is on the
proposer to overcome objections.

Other alternative approaches to scaling Bitcoin payments have been prop= osed such as with validation rollups[^7], enabled
by the ability to verify a zero-knowledge proof directly in Bitcoin Scr= ipt. These rollups are trustless and could
effectuate a modest factor throughput increase under realistic assumpti= ons and transaction load. This approach, used on
altcoins but new to Bitcoin, has yet to reach consensus among the techn= ical community and Bitcoin users more broadly.
Relative immaturity of many of the employed crypto-systems make designi= ng a ZKP-specific primitive a difficult task.
Further, trustless composibility with interactive protocols like LN to = achieve further scaling are speculative at the
time. Nonetheless, the capabilities that enable this alternative approa= ch to scaling are neither exclusionary nor
redundant with those proposed here.

It makes sense to focus first on capabilities improving the tried-and-p= roven approach, as the newer approach
(and the capabilities enabling it) may come with different tradeoffs.

Yet another alternative is a set of more powerful capabilities, enablin= g the use cases that "commit to next transaction"
and "verify a BIP340 signature for an arbitrary message" enab= le and more. For instance replacing "commit to the exact
transaction which must spend this output" with "programmable = introspection on the spending transaction's fields" has
been considered. However this approach increases implementation complex= ity and broadens the risk surface[^8], which
warrants a compelling demonstration that arbitrary transaction introspe= ction does enable important use cases not
achievable with more minimal capabilities.

Finally, a more radical alternative is to focus efforts to make Bitcoin= smart contracts more capable with a sane
re-design of its scripting language. Similarly to the alternative of mo= re powerful Bitcoin Script capabilities, it
remains to be shown that more expressivity is both safe and desirable. = Furthermore, it is unclear that such an
undertaking would be achievable with the (very) limited engineering res= ources currently allocated to extending Bitcoin
scripting capabilities.

In conclusion, we believe the bundle of capabilities "commitment t= o the transaction spending an output" and "BIP340
signature verification of arbitrary message" to be the best direct= ion for Bitcoin to take. These are well-understood,
simple capabilities, substantially improving an existing well-understoo= d approach to scaling Bitcoin payments. This
direction does not preclude research into more advanced capabilities, t= hough questions remain about their overall
desirability.

Antoine Poinsot & Greg Sanders

[^0]: https://delvingbitcoin.org/t/ln-symmetry-projec= t-recap/359
[^1]: https://delvingbitcoin.org/t/the-ark-case-for-ctv/1528<= /a>
[^2]: https://gnusha.org/pi/bitcoindev/CAH5Bsr= 2vxL3FWXnJTszMQj83...@mail.gmail.com
[^3]: https://delvingbitcoin.or= g/t/how-ctv-csfs-improves-bitvm-bridges/1591
[^4]: https://d= elvingbitcoin.org/t/non-confiscatory-transaction-weight-limit/1732/8
[^5]: https:/= /delvingbitcoin.org/t/evolving-the-ark-protocol-using-ctv-and-csfs/1602
[^6]: https://delvingbitcoin.org/t/ctv-= csfs-can-we-reach-consensus-on-a-first-step-towards-covenants/1509/18
[^7]: https://github.com/john-light/validity-rollups
[^8]: https://bluematt.bitcoin.ninja/2024/04/16= /stop-calling-it-mev

--
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/b98ba037-a76b-4fac-88c2-b9f9fbca87cbn%40googlegroups.com.
------=_Part_46549_1384171008.1750775365798-- ------=_Part_46548_1481345427.1750775365798--