From: Matt Corallo <lf-lists@mattcorallo.com>
To: "David A. Harding" <dave@dtrt.org>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV
Date: Thu, 21 Apr 2022 07:58:39 -0700 [thread overview]
Message-ID: <d95eec37-269d-eefb-d191-e8234e4faed3@mattcorallo.com> (raw)
In-Reply-To: <64a34b4d46461da322be51b53ec2eb01@dtrt.org>
On 4/20/22 6:04 PM, David A. Harding via bitcoin-dev wrote:
> Hi all,
>
> The main criticisms I'm aware of against CTV seem to be along the following lines:
>
> 1. Usage, either:
> a. It won't receive significant real-world usage, or
> b. It will be used but we'll end up using something better later
> 2. An unused CTV will need to be supported forever, creating extra maintenance
> burden, increasing security surface, and making it harder to evaluate later
> consensus change proposals due to their interactions with CTV
>
Also "is this even the way we should be going about covenants?" Given there are still various
proposals for covenants floating around and we're still in the very early stages of the
reconciliation of them and the Bitcoin technical community (or at least those interested in working
on covenants) doesn't even remotely show any signs of consensus around any concrete proposal,
talking about a "way forward for CTV" or activating CTV or coming up with some way of shoving it
into Bitcoin at this stage is insulting, myopic, short-sighted. Worse, it sets incredibly poor
precedent for how we think about changes to Bitcoin and maintaining Bitcoin's culture of security
and careful design.
I'm gobsmacked that the conversation has reached this point, and am even more surprised that the
response from the Bitcoin (technical) community hasn't been a more resounding and complete rejection
of this narrative.
Matt
next prev parent reply other threads:[~2022-04-21 14:58 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-21 1:04 [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV David A. Harding
2022-04-21 2:05 ` Luke Dashjr
2022-04-21 3:10 ` alicexbt
2022-04-21 5:56 ` Luke Dashjr
2022-04-21 6:20 ` Jeremy Rubin
2022-04-21 6:37 ` Luke Dashjr
2022-04-21 13:10 ` Jeremy Rubin
2022-04-24 15:22 ` Peter Todd
2022-04-21 14:58 ` Matt Corallo [this message]
2022-04-21 18:06 ` David A. Harding
2022-04-21 18:39 ` Matt Corallo
2022-04-21 22:28 ` David A. Harding
2022-04-21 23:02 ` Matt Corallo
2022-04-22 1:20 ` David A. Harding
2022-04-22 18:40 ` Matt Corallo
2022-04-22 18:49 ` Corey Haddad
2022-04-22 16:48 ` James O'Beirne
2022-04-22 17:06 ` James O'Beirne
2022-04-22 16:28 ` James O'Beirne
2022-04-22 17:25 ` [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks) Russell O'Connor
2022-04-23 4:56 ` Billy Tetrud
2022-04-23 14:02 ` Russell O'Connor
2022-04-23 18:24 ` Matt Corallo
2022-04-23 19:30 ` Russell O'Connor
2022-04-24 23:03 ` Billy Tetrud
2022-04-25 17:27 ` Nadav Ivgi
2022-04-25 22:27 ` Russell O'Connor
2022-04-27 1:52 ` Billy Tetrud
2022-04-28 23:14 ` Nadav Ivgi
2022-04-28 23:51 ` Billy Tetrud
2022-04-22 18:35 ` [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV Matt Corallo
2022-04-21 19:08 ` Jeremy Rubin
2022-04-22 0:28 ` Anthony Towns
2022-04-22 1:44 ` David A. Harding
2022-04-22 19:57 ` Antoine Riard
2022-04-25 5:12 ` ZmnSCPxj
2022-04-22 19:05 alicexbt
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=d95eec37-269d-eefb-d191-e8234e4faed3@mattcorallo.com \
--to=lf-lists@mattcorallo.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=dave@dtrt.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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