path: root/dc/4ae871d0b183b75023d4fdfb1e30c3b072a063

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 <bitcoindev+bncBDAIH2GWWYHBB54A5PBAMGQEVHFCYLA@googlegroups.com>)
	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 <bitcoindev@gnusha.org>; 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 <harshagoli@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <b98ba037-a76b-4fac-88c2-b9f9fbca87cbn@googlegroups.com>
In-Reply-To: <F5vsDVNGXP_hmCvp4kFnptFLBCXOoRxWk9d05kSInq_kXj0ePqVAJGADkBFJxYIGkjk8Pw1gzBonTivH6WUUb4f6mwNCmJIwdXBMrjjQ0lI=@protonmail.com>
References: <F5vsDVNGXP_hmCvp4kFnptFLBCXOoRxWk9d05kSInq_kXj0ePqVAJGADkBFJxYIGkjk8Pw1gzBonTivH6WUUb4f6mwNCmJIwdXBMrjjQ0lI=@protonmail.com>
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: <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.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
> <https://gnusha.org/pi/bitcoindev/CAH5Bsr2vxL3FWXnJTszMQj83jTVdRvvuVpimEf=
Y7JpFCyP1AZA@mail.gmail.com>
> [^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

<blockquote style=3D"padding: 0px 0px 0px 20px; background-size: 1px 1px; b=
ackground-position: 0% 50%; background-repeat: repeat-y; font-family: &quot=
;Superhuman Adelle Email&quot;, color-emoji-override, sans-serif, &quot;App=
le Color Emoji&quot;, emoji-flag-fallbacks, &quot;Segoe UI Emoji&quot;, &qu=
ot;Noto Color Emoji&quot;; margin: 0px; border-left: 0px; color: rgba(0, 0,=
 0, 0.6); font-feature-settings: initial; line-height: 24px;"><div style=3D=
"font-feature-settings: initial; line-height: 24px; background-color: rgba(=
0, 0, 0, 0);">=E2=80=8B<span style=3D"font-feature-settings: initial; line-=
height: 24px; background-color: rgba(0, 0, 0, 0);">We will start by making =
the case that the capabilities "commit to the transaction spending this out=
put"</span><br style=3D"font-feature-settings: initial; line-height: 24px;"=
 /></div><div style=3D"font-feature-settings: initial; line-height: 24px; b=
ackground-color: rgba(0, 0, 0, 0);"><span style=3D"font-feature-settings: i=
nitial; line-height: 24px; background-color: rgba(0, 0, 0, 0);">and "verify=
 a BIP340 signature for an arbitrary message" are a good stopping point for=
 a Bitcoin soft fork. We invite</span><br style=3D"font-feature-settings: i=
nitial; line-height: 24px;" /></div><div style=3D"font-feature-settings: in=
itial; line-height: 24px; background-color: rgba(0, 0, 0, 0);"><span style=
=3D"font-feature-settings: initial; line-height: 24px; background-color: rg=
ba(0, 0, 0, 0);">anyone to share objections in reply to this thread so they=
 can be addressed or inform a better course of action.</span><br style=3D"f=
ont-feature-settings: initial; line-height: 24px;" /></div></blockquote><di=
v style=3D"font-family: &quot;Superhuman Adelle Email&quot;, color-emoji-ov=
erride, sans-serif, &quot;Apple Color Emoji&quot;, emoji-flag-fallbacks, &q=
uot;Segoe UI Emoji&quot;, &quot;Noto Color Emoji&quot;; color: rgba(0, 0, 0=
, 0.9); font-feature-settings: initial; line-height: 24px;"><div style=3D"f=
ont-feature-settings: initial; line-height: 24px; background-color: rgba(0,=
 0, 0, 0);"><br style=3D"font-feature-settings: initial; line-height: 24px;=
" /></div><div style=3D"font-feature-settings: initial; line-height: 24px; =
background-color: rgba(0, 0, 0, 0);">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.<br style=3D"font-feature-settings: initial; line-height: 24px;" /></d=
iv><div style=3D"font-feature-settings: initial; line-height: 24px; backgro=
und-color: rgba(0, 0, 0, 0);"><br style=3D"font-feature-settings: initial; =
line-height: 24px;" /></div><div style=3D"font-feature-settings: initial; l=
ine-height: 24px; background-color: rgba(0, 0, 0, 0);">Thanks,<br style=3D"=
font-feature-settings: initial; line-height: 24px;" /></div><div style=3D"f=
ont-feature-settings: initial; line-height: 24px; background-color: rgba(0,=
 0, 0, 0);">Harsha, sometimes known as arshbot</div></div><br /><div class=
=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">On Monday, June 23,=
 2025 at 9:26:20=E2=80=AFAM UTC-4 Antoine Poinsot wrote:<br/></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0 0 0 0.8ex; border-left: 1px so=
lid rgb(204, 204, 204); padding-left: 1ex;">There is excitement in the tech=
nical community about a CTV+CSFS soft fork as specified in BIP119 and BIP34=
8. We think
<br>this combination of opcodes offers desirable capabilities to scale Bitc=
oin payments and is worth considering to soft
<br>fork into Bitcoin. There has been several objections to this proposal, =
which we can group into three categories:
<br>exploration of alternatives, demonstration of usage, and design of the =
operations to achieve these capabilities.
<br>
<br>In an attempt to help the proposal move forward we would like to kick-o=
ff a discussion about the first category:
<br>alternatives. We will start by making the case that the capabilities &q=
uot;commit to the transaction spending this output&quot;
<br>and &quot;verify a BIP340 signature for an arbitrary message&quot; are =
a good stopping point for a Bitcoin soft fork. We invite
<br>anyone to share objections in reply to this thread so they can be addre=
ssed or inform a better course of action.
<br>
<br>Let&#39;s keep the discussion focused on the capabilities, not the spec=
ific way of designing operations to achieve them. For
<br>the sake of this discussion `OP_CTV` would be equivalent to `OP_TEMPLAT=
EHASH` (push the template hash on the stack) as
<br>the capability &quot;commit to the transaction to spend an output&quot;=
. `OP_TXHASH` would be separate, as a &quot;programmable
<br>transaction introspection&quot; capability.
<br>
<br>The ability to commit to the exact transaction spending an output is us=
eful to reduce interactivity in second-layer
<br>protocols. For instance it can reduce roundtrips[^0] in the implementat=
ion of LN-Symmetry, or make receiving an Ark
<br>&quot;vtxo&quot; non-interactive[^1]. Additionally, it enables signific=
ant optimizations[^2] in the implementation of Discreet Log
<br>Contracts.
<br>
<br>The ability to verify a signature for an arbitrary message in Tapscript=
 enables oracle attestations and a form of
<br>delegation. Oracle attestation for instance significantly reduce[^3] th=
e onchain footprint of BitVM. Reducing an
<br>application&#39;s onchain footprint benefits all Bitcoin users by easin=
g block space competition, and it&#39;s especially
<br>important for applications that generate very large transactions, which=
 could otherwise increase pressure toward mining
<br>centralization[^4].
<br>
<br>Together, these two features enable a third capability: rebindable tran=
saction signatures. Rebindable signatures make
<br>possible a new type of payment channels, LN-Symmetry (&quot;Eltoo&quot;=
), whose simplicity makes practical advanced constructs
<br>such as multiparty channels. They also enable further interactivity red=
uction in second layer protocols, as illustrated
<br>by the Ark variant &quot;Erk&quot;[^5] or the dramatic simplification[^=
6] they bring to upgrading today&#39;s Lightning (i.e. without
<br>switching to LN-Symmetry) from HTLCs to PTLCs.
<br>
<br>These capabilities are simple and modular. They are well understood and=
 present a low risk of enabling unwanted
<br>behaviour. They do not increase the cost of validation, have low implem=
entation complexity and are unlikely to become
<br>redundant, even if more powerful capabilities are added in the future. =
These capabilities improve existing
<br>tried-and-proven protocols used daily by Bitcoin users, like the Lightn=
ing Network. They also make new ones possible
<br>either at all or through realistic interactivity requirements. The new =
enabled protocols take a similar approach to
<br>existing Bitcoin scaling solutions, only with different tradeoffs not p=
reviously available. We can therefore reasonably
<br>expect they won&#39;t introduce new systemic incentives, while broadeni=
ng the range of supported use cases.
<br>
<br>The first alternative approach to address is doing nothing. Doing nothi=
ng is *the* valid schelling point in a system
<br>where consensus changes must be agreed on by a supermajority of the eco=
nomic activity, and ideally by all stakeholders
<br>in the system. Unless there is a critical vulnerability being fixed, th=
e onus is on the proposer to overcome the various
<br>valid objections. Further, a number of smart contracts have been deploy=
ed on Bitcoin and more are incoming, with or
<br>without consensus changes. No softforks on the horizon are known to gen=
erate asymptotic scaling, and what&#39;s more,
<br>on-chain demand has not been high except on infrequent intervals.
<br>
<br>As said prior, we believe the capabilities of CTV+CSFS reach an appropr=
iate bar for consideration for activation. While
<br>it will not achieve asymptotic scaling, it will enable significant redu=
ction in complexity in already-deployed systems,
<br>and is worth deploying for their specific benefits. Regardless, it&#39;=
s important to emphasize it again: the onus is on the
<br>proposer to overcome objections.
<br>
<br>Other alternative approaches to scaling Bitcoin payments have been prop=
osed such as with validation rollups[^7], enabled
<br>by the ability to verify a zero-knowledge proof directly in Bitcoin Scr=
ipt. These rollups are trustless and could
<br>effectuate a modest factor throughput increase under realistic assumpti=
ons and transaction load.  This approach, used on
<br>altcoins but new to Bitcoin, has yet to reach consensus among the techn=
ical community and Bitcoin users more broadly.
<br>Relative immaturity of many of the employed crypto-systems make designi=
ng a ZKP-specific primitive a difficult task.
<br>Further, trustless composibility with interactive protocols like LN to =
achieve further scaling are speculative at the
<br>time. Nonetheless, the capabilities that enable this alternative approa=
ch to scaling are neither exclusionary nor
<br>redundant with those proposed here.
<br>
<br>It makes sense to focus first on capabilities improving the tried-and-p=
roven approach, as the newer approach
<br>(and the capabilities enabling it) may come with different tradeoffs.
<br>
<br>Yet another alternative is a set of more powerful capabilities, enablin=
g the use cases that &quot;commit to next transaction&quot;
<br>and &quot;verify a BIP340 signature for an arbitrary message&quot; enab=
le and more. For instance replacing &quot;commit to the exact
<br>transaction which must spend this output&quot; with &quot;programmable =
introspection on the spending transaction&#39;s fields&quot; has
<br>been considered. However this approach increases implementation complex=
ity and broadens the risk surface[^8], which
<br>warrants a compelling demonstration that arbitrary transaction introspe=
ction does enable important use cases not
<br>achievable with more minimal capabilities.
<br>
<br>Finally, a more radical alternative is to focus efforts to make Bitcoin=
 smart contracts more capable with a sane
<br>re-design of its scripting language. Similarly to the alternative of mo=
re powerful Bitcoin Script capabilities, it
<br>remains to be shown that more expressivity is both safe and desirable. =
Furthermore, it is unclear that such an
<br>undertaking would be achievable with the (very) limited engineering res=
ources currently allocated to extending Bitcoin
<br>scripting capabilities.
<br>
<br>In conclusion, we believe the bundle of capabilities &quot;commitment t=
o the transaction spending an output&quot; and &quot;BIP340
<br>signature verification of arbitrary message&quot; to be the best direct=
ion for Bitcoin to take. These are well-understood,
<br>simple capabilities, substantially improving an existing well-understoo=
d approach to scaling Bitcoin payments. This
<br>direction does not preclude research into more advanced capabilities, t=
hough questions remain about their overall
<br>desirability.
<br>
<br>Antoine Poinsot &amp; Greg Sanders
<br>
<br>[^0]: <a href=3D"https://delvingbitcoin.org/t/ln-symmetry-project-recap=
/359" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://ww=
w.google.com/url?hl=3Den&amp;q=3Dhttps://delvingbitcoin.org/t/ln-symmetry-p=
roject-recap/359&amp;source=3Dgmail&amp;ust=3D1750861754041000&amp;usg=3DAO=
vVaw3lMuezxQFUL4lXlld4IDp3">https://delvingbitcoin.org/t/ln-symmetry-projec=
t-recap/359</a>
<br>[^1]: <a href=3D"https://delvingbitcoin.org/t/the-ark-case-for-ctv/1528=
" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.go=
ogle.com/url?hl=3Den&amp;q=3Dhttps://delvingbitcoin.org/t/the-ark-case-for-=
ctv/1528&amp;source=3Dgmail&amp;ust=3D1750861754041000&amp;usg=3DAOvVaw13Vl=
Ikz-k7fPr56gyNANyv">https://delvingbitcoin.org/t/the-ark-case-for-ctv/1528<=
/a>
<br>[^2]: <a href=3D"https://gnusha.org/pi/bitcoindev/CAH5Bsr2vxL3FWXnJTszM=
Qj83jTVdRvvuVpimEfY7JpFCyP1AZA@mail.gmail.com" target=3D"_blank" rel=3D"nof=
ollow" data-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dh=
ttps://gnusha.org/pi/bitcoindev/CAH5Bsr2vxL3FWXnJTszMQj83jTVdRvvuVpimEfY7Jp=
FCyP1AZA@mail.gmail.com&amp;source=3Dgmail&amp;ust=3D1750861754041000&amp;u=
sg=3DAOvVaw19hZm3vEKzLFDaAFpGbpj4">https://gnusha.org/pi/bitcoindev/CAH5Bsr=
2vxL3FWXnJTszMQj83...@mail.gmail.com</a>
<br>[^3]: <a href=3D"https://delvingbitcoin.org/t/how-ctv-csfs-improves-bit=
vm-bridges/1591" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D=
"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://delvingbitcoin.org/t/ho=
w-ctv-csfs-improves-bitvm-bridges/1591&amp;source=3Dgmail&amp;ust=3D1750861=
754041000&amp;usg=3DAOvVaw2vFeGV7ly113XQOQhmrhY5">https://delvingbitcoin.or=
g/t/how-ctv-csfs-improves-bitvm-bridges/1591</a>
<br>[^4]: <a href=3D"https://delvingbitcoin.org/t/non-confiscatory-transact=
ion-weight-limit/1732/8" target=3D"_blank" rel=3D"nofollow" data-saferedire=
cturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://delvingbitcoin.=
org/t/non-confiscatory-transaction-weight-limit/1732/8&amp;source=3Dgmail&a=
mp;ust=3D1750861754041000&amp;usg=3DAOvVaw1BcbifOIeIosVyywi9xa7l">https://d=
elvingbitcoin.org/t/non-confiscatory-transaction-weight-limit/1732/8</a>
<br>[^5]: <a href=3D"https://delvingbitcoin.org/t/evolving-the-ark-protocol=
-using-ctv-and-csfs/1602" target=3D"_blank" rel=3D"nofollow" data-saferedir=
ecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://delvingbitcoin=
.org/t/evolving-the-ark-protocol-using-ctv-and-csfs/1602&amp;source=3Dgmail=
&amp;ust=3D1750861754041000&amp;usg=3DAOvVaw341m478Yj5H47j55l7O64Y">https:/=
/delvingbitcoin.org/t/evolving-the-ark-protocol-using-ctv-and-csfs/1602</a>
<br>[^6]: <a href=3D"https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-con=
sensus-on-a-first-step-towards-covenants/1509/18" target=3D"_blank" rel=3D"=
nofollow" data-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=
=3Dhttps://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-=
step-towards-covenants/1509/18&amp;source=3Dgmail&amp;ust=3D175086175404100=
0&amp;usg=3DAOvVaw3YXHSPM3Exf4EdVKQk231b">https://delvingbitcoin.org/t/ctv-=
csfs-can-we-reach-consensus-on-a-first-step-towards-covenants/1509/18</a>
<br>[^7]: <a href=3D"https://github.com/john-light/validity-rollups" target=
=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.google.com=
/url?hl=3Den&amp;q=3Dhttps://github.com/john-light/validity-rollups&amp;sou=
rce=3Dgmail&amp;ust=3D1750861754042000&amp;usg=3DAOvVaw2Dqn5ggBPee57oeyMNOz=
DH">https://github.com/john-light/validity-rollups</a>
<br>[^8]: <a href=3D"https://bluematt.bitcoin.ninja/2024/04/16/stop-calling=
-it-mev" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https:/=
/www.google.com/url?hl=3Den&amp;q=3Dhttps://bluematt.bitcoin.ninja/2024/04/=
16/stop-calling-it-mev&amp;source=3Dgmail&amp;ust=3D1750861754042000&amp;us=
g=3DAOvVaw2jYQsRzMtuT0nBUzwdFTbF">https://bluematt.bitcoin.ninja/2024/04/16=
/stop-calling-it-mev</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/b98ba037-a76b-4fac-88c2-b9f9fbca87cbn%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/b98ba037-a76b-4fac-88c2-b9f9fbca87cbn%40googlegroups.com</a>.<br />

------=_Part_46549_1384171008.1750775365798--

------=_Part_46548_1481345427.1750775365798--