There is excitement in the technical community about a CTV+CSFS soft fork as
specified in BIP119 and BIP348. We think
this combination of opcodes offers desirable capabilities to scale Bitcoin
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-off a
discussion about the first category:
alternatives. We will start by making the case that the capabilities "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 addressed or
inform a better course of action.
Let's keep the discussion focused on the capabilities, not the specific way of
designing operations to achieve them. For
the sake of this discussion `OP_CTV` would be equivalent to `OP_TEMPLATEHASH`
(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 useful to
reduce interactivity in second-layer
protocols. For instance it can reduce roundtrips[^0] in the implementation of
LN-Symmetry, or make receiving an Ark
"vtxo" non-interactive[^1]. Additionally, it enables significant
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] the
onchain footprint of BitVM. Reducing an
application's onchain footprint benefits all Bitcoin users by easing 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 transaction
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 reduction
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 implementation
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 Lightning
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
previously available. We can therefore reasonably
expect they won't introduce new systemic incentives, while broadening the range
of supported use cases.
The first alternative approach to address is doing nothing. Doing nothing is
*the* valid schelling point in a system
where consensus changes must be agreed on by a supermajority of the economic
activity, and ideally by all stakeholders
in the system. Unless there is a critical vulnerability being fixed, the onus
is on the proposer to overcome the various
valid objections. Further, a number of smart contracts have been deployed on
Bitcoin and more are incoming, with or
without consensus changes. No softforks on the horizon are known to 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 appropriate bar
for consideration for activation. While
it will not achieve asymptotic scaling, it will enable significant reduction 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 proposed
such as with validation rollups[^7], enabled
by the ability to verify a zero-knowledge proof directly in Bitcoin Script.
These rollups are trustless and could
effectuate a modest factor throughput increase under realistic assumptions and
transaction load. This approach, used on
altcoins but new to Bitcoin, has yet to reach consensus among the technical
community and Bitcoin users more broadly.
Relative immaturity of many of the employed crypto-systems make designing 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 approach to
scaling are neither exclusionary nor
redundant with those proposed here.
It makes sense to focus first on capabilities improving the 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 the
use cases that "commit to next transaction"
and "verify a BIP340 signature for an arbitrary message" enable 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 complexity and
broadens the risk surface[^8], which
warrants a compelling demonstration that arbitrary transaction introspection
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 more
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 resources
currently allocated to extending Bitcoin
scripting capabilities.
In conclusion, we believe the bundle of capabilities "commitment to the
transaction spending an output" and "BIP340
signature verification of arbitrary message" to be the best direction for
Bitcoin to take. These are well-understood,
simple capabilities, substantially improving an existing well-understood
approach to scaling Bitcoin payments. This
direction does not preclude research into more advanced capabilities, 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]:
https://gnusha.org/pi/bitcoindev/cah5bsr2vxl3fwxnjtszmqj83jtvdrvvuvpimefy7jpfcyp1...@mail.gmail.com
[^3]: https://delvingbitcoin.org/t/how-ctv-csfs-improves-bitvm-bridges/1591
[^4]:
https://delvingbitcoin.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
"Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/bitcoindev/F5vsDVNGXP_hmCvp4kFnptFLBCXOoRxWk9d05kSInq_kXj0ePqVAJGADkBFJxYIGkjk8Pw1gzBonTivH6WUUb4f6mwNCmJIwdXBMrjjQ0lI%3D%40protonmail.com.
