From: Matt Corallo <lf-lists@mattcorallo•com>
To: Adam Back <adam@cypherspace•org>
Cc: Michael Folkson <michaelfolkson@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
Date: Fri, 19 Feb 2021 09:13:00 -0500 [thread overview]
Message-ID: <E3E39A9A-82B4-4096-9DA1-A4D758CC7B68@mattcorallo.com> (raw)
In-Reply-To: <CALqxMTFKbjg3yDPnrmL8TgtypirB_fDMMJD=AJxjYav51hmEAw@mail.gmail.com>
(Also in response to ZMN...)
Bitcoin Core has a long-standing policy of not shipping options which shoot yourself in the foot. I’d be very disappointed if that changed now. People are of course more than welcome to run such software themselves, but I anticipate the loud minority on Twitter and here aren’t processing enough transactions or throwing enough financial weight behind their decision for them to do anything but just switch back if they find themselves on a chain with no blocks.
There’s nothing we can (or should) do to prevent people from threatening to (and possibly) forking themselves off of bitcoin, but that doesn’t mean we should encourage it either. The work Bitcoin Core maintainers and developers do is to recommend courses of action which they believe have reasonable levels of consensus and are technically sound. Luckily, there’s strong historical precedent for people deciding to run other software around forks, so misinterpretation is not very common (just like there’s strong historical precedent for miners not unilaterally deciding forks in the case of Segwit).
Matt
> On Feb 19, 2021, at 07:08, Adam Back <adam@cypherspace•org> wrote:
>> would dev consensus around releasing LOT=false be considered as "developers forcing their views on users"?
>
> given there are clearly people of both views, or for now don't care
> but might later, it would minimally be friendly and useful if
> bitcoin-core has a LOT=true option - and that IMO goes some way to
> avoid the assumptive control via defaults.
> Otherwise it could be read as saying "developers on average
> disapprove, but if you, the market disagree, go figure it out for
> yourself" which is not a good message for being defensive and avoiding
> mis-interpretation of code repositories or shipped defaults as
> "control".
next prev parent reply other threads:[~2021-02-19 14:13 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-17 12:51 Michael Folkson
2021-02-18 5:43 ` Ariel Lorenzo-Luaces
2021-02-18 11:01 ` Michael Folkson
2021-02-18 11:11 ` Samson Mow
2021-02-18 11:52 ` ZmnSCPxj
2021-02-18 12:20 ` Michael Folkson
2021-02-18 14:01 ` Matt Corallo
2021-02-18 14:26 ` Michael Folkson
2021-02-18 14:42 ` Matt Corallo
2021-02-18 14:51 ` Michael Folkson
2021-02-18 14:53 ` Matt Corallo
2021-02-18 15:01 ` Matt Corallo
2021-02-18 15:04 ` Keagan McClelland
2021-02-18 15:18 ` Matt Corallo
2021-02-19 2:20 ` Ariel Luaces
2021-02-19 11:30 ` ZmnSCPxj
2021-02-19 12:05 ` Adam Back
2021-02-19 14:13 ` Matt Corallo [this message]
2021-02-19 17:48 ` Matt Corallo
2021-02-20 2:55 ` ZmnSCPxj
2021-02-20 17:20 ` Ariel Lorenzo-Luaces
2021-02-21 14:30 ` Matt Corallo
2021-02-22 5:16 ` Anthony Towns
2021-02-22 6:44 ` Matt Corallo
2021-02-22 10:16 ` Anthony Towns
2021-02-22 14:00 ` Matt Corallo
2021-02-22 16:27 ` Anthony Towns
2021-02-22 16:31 ` Jorge Timón
2021-02-22 16:48 ` Jorge Timón
2021-02-23 2:10 ` Jeremy
2021-02-23 19:33 ` Keagan McClelland
2021-02-23 23:14 ` Ben Woosley
2021-02-24 22:37 ` Ariel Luaces
2021-03-01 13:54 ` Erik Aronesty
2021-03-02 18:32 ` Ariel Lorenzo-Luaces
2021-02-24 7:18 ` Anthony Towns
2021-02-18 13:59 ` Matt Corallo
2021-02-21 16:21 ` Erik Aronesty
2021-02-19 22:12 Matt Hill
2021-02-19 23:30 ` Matt Corallo
2021-02-19 23:42 ` Bryan Bishop
2021-02-21 10:10 Prayank
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=E3E39A9A-82B4-4096-9DA1-A4D758CC7B68@mattcorallo.com \
--to=lf-lists@mattcorallo$(echo .)com \
--cc=adam@cypherspace$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=michaelfolkson@gmail$(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