From: Peter Todd <pete@petertodd•org>
To: Michael Folkson <michaelfolkson@protonmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt
Date: Sun, 9 Jan 2022 06:38:15 -0500 [thread overview]
Message-ID: <YdrJJ3VxoxHVgg7Y@petertodd.org> (raw)
In-Reply-To: <XuO20TMFGBqz53WYWxi9bgAdB3iGmqEIUE84AupRxCpHQVd3-YbGVzZUFz21dOgb_AgwlGWaruzE8NGxhes6HCKHpRZLmL1d1kNu1yobAIU=@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 6057 bytes --]
On Mon, Jan 03, 2022 at 02:05:20AM +0000, Michael Folkson via bitcoin-dev wrote:
> There have been a number of “soft signals”, many expressing enthusiasm for the speculated use cases of OP_CTV. Personally I share that enthusiasm like I do with the prospect of curing cancer. But these soft signals seem as if they are going to be used to attempt to justify an imminent contentious soft fork attempt. The devil is in the details both with regards to wording like “reasonable parameters” and the utility and safety of a new opcode. Indeed if you share my concerns that there has not been sufficient scrutiny and research on the long implications of this proposal I encourage you to register a soft signal of “No” on the site like I have. You can always change it to “Yes” if and when you support an imminent soft fork activation attempt containing exclusively OP_CTV. Enabling covenants on Bitcoin is a big step change with barely any existing research on the topic and attempting to rush it through by the back door so soon after Taproot activation should be resisted. To look at the ~200 lines of code for the opcode exclusively (of course this should be done too) in a vacuum without considering the broader implications is also incredibly shortsighted. The only thing stopping a descent into Ethereum style seat of our pants consensus changes is community vigilance. If we ever lose that we lose the foundation of this industry.
I have to second your objections.
I spent a bit of time over the past week looking at the current state of
OP_CTV/BIP-0119, and I too think it's a premature idea with an insufficient BIP
and reference implementation, that current lacks compelling use-cases clearly
beneficial to all users.
Remember that Bitcoin is a nearly $1 trillion network with tens of millions of
users that has gotten to that point with careful, conservative engineering.
Every change to the protocol poses risks to those users. Previous feature
upgrades to the Bitcoin protocol have always been done with the intent of
improving the protocol for everyone: CSV/segwit benefit all users via
Lightning, because we can reasonably all users to directly take advantage of
those features. We expect _everyone_ to benefit from Taproot via improved
privacy. I don't think CTV in its current form makes that case sufficiently,
and the technical details are lacking.
As for some more detailed thoughts, for clarify, I'm referring to:
https://github.com/bitcoin/bips/blob/3693cdfd192dacdac89cd742f68cd1bb96bf7f7e/bip-0119.mediawiki
https://github.com/JeremyRubin/bitcoin/tree/8f313d292e426a74d9ce28e5130bbf0cd48f867e
By no means is this a complete list of issues:
# DoS Attacks
Note how above I cited the git hashes to make it clear what exactly I'm
referring too: the fact that the reference implementation is listed as
https://github.com/JeremyRubin/bitcoin/tree/checktemplateverify in the BIP is
an immediate problem, as it's not clear what exactly is the specification.
This in turn matters quite a lot, because the BIP itself glosses over the quite
serious DoS attack issues involved in adding more ways that opcodes can hash
txs. Strong resistance to DoS attacks is a _mandatory_ aspect of all Bitcoin
script proposals, so leaving those details to a mostly uncommented reference
implementation without a clear discussion of those trade-offs is insufficient.
# Use Cases
As Folkson notes, these are barely fleshed out:
## Congestion Controlled Transactions
While this section appears somewhat fleshed out, with even a simulation, it
completely ignores the numerous practical issues like the need for
communication channels between wallets to inform them of the existence of these
batches. It also raises an important question: who needs this? On-chain
transactions are clearly not the future of Bitcoin and this use-case will
likely impact a small % of users.
## Wallet Vaults
This use-case can be easily tested, even in production, right now with
additional "oracle" signers that simply verify the CTV rules have been
followed.
## Payment Channels
These use-cases sound promising. But they all need to be clearly fleshed out as
actually taking advantage of them is quite complex.
## CoinJoin
> because participants agree on a single output which pays all participants,
> which will be lower fee than before
It is not clear how the fee will be lower, given that taking advantage of CTV
means there are more transactions, not less.
# Covenant Design Trade-Offs and Risks
> Covenants have historically been controversial given their potential for
> fungibility risks -- coins could be minted which have a permanent restriction
> on how they may or may not be spent or required to propagate metadata.
Indeed, this is a significant risk with the potential to harm all Bitcoin
users.
> In the CHECKTEMPLATEVERIFY approach, the covenants are severely restricted to
> simple templates. The structure of CHECKTEMPLATEVERIFY template is such that
> the outputs must be known exactly at the time of construction. Based on a
> destructuring argument, it is only possible to create templates which expand
> in a finite number of steps. Thus templated transactions are in theory as
> safe as transactions which create all the inputs directly in this regard.
The "finite" number of steps could be millions of transactions - "infinitely
long" for any practical purpose.
# Test Vectors
Currently the testing is poorly documented, without clear goals as to what edge
cases are actually being tested:
https://github.com/JeremyRubin/bitcoin/commit/e026bae28a774d91effc32862d0246286c114c24
Also, we really need test _vectors_ rather than a Python test: for consenus,
you want to write down explicitly the *data* in the form of serialized
transactions that is being fed into the consensus engine, to avoid mistakes in
test coverage due to broken test harnesses.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2022-01-10 18:30 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-03 2:05 Michael Folkson
2022-01-09 11:38 ` Peter Todd [this message]
2022-01-11 3:42 ` Jeremy
2022-01-11 4:38 ` Jeremy
2022-01-04 11:53 Prayank
2022-01-04 14:15 ` Michael Folkson
2022-01-04 15:06 ` Prayank
2022-01-04 16:48 ` Michael Folkson
2022-01-04 17:07 ` Prayank
2022-01-04 14:42 ` Christian Decker
2022-01-04 15:45 ` Prayank
2022-01-18 1:57 Prayank
2022-02-18 23:41 ` Peter Todd
2022-02-20 18:35 ` Erik Aronesty
2022-02-21 3:03 ` Prayank
2022-02-21 9:02 ` ZmnSCPxj
2022-02-21 9:11 ` ZmnSCPxj
2022-02-21 9:48 ` Prayank
2022-02-22 12:57 ` Billy Tetrud
2022-02-21 9:09 ` ZmnSCPxj
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YdrJJ3VxoxHVgg7Y@petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=michaelfolkson@protonmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox