From: Anthony Towns <aj@erisian•com.au>
To: Matt Corallo <lf-lists@mattcorallo•com>
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: Tue, 23 Feb 2021 02:27:40 +1000 [thread overview]
Message-ID: <20210222162740.mif2uygjszupizqc@erisian.com.au> (raw)
In-Reply-To: <7B0D8EE4-19D9-4686-906C-F762F29E74D4@mattcorallo.com>
On Mon, Feb 22, 2021 at 09:00:29AM -0500, Matt Corallo wrote:
> I think it should be clear that a UASF-style command line option to allow
> consensus rule changes in the node in the short term, immediately before a fork
> carries some risk of a fork, even if I agree it may not persist over months. We
> can’t simply ignore that.
I don't think a "-set-bip8-lockinontimeout=taproot" option on its own
would be very safe -- if we were sure it was safe, because we were sure
that everyone would eventually set lockinontimeout=true, then we would
set lockinontimeout=true from day one and not need an option. I haven't
seen/had any good ideas on how to make the option safe, or at least make
it obvious that you shouldn't be setting it if you don't really
understand what you're getting yourself into. [0]
And that's even if you assume that the code was perfectly capable of
handling forks in some theoretically optimal way.
So at least for the time being, I don't think a config param / command
line option is a good idea for bip8. IMHO, YMMV, IANABDFL etc.
> I think the important specific case of this is something like "if a chain
> where taproot is impossible to activate is temporarily the most work,
> miners with lockinontimeout=true need to be well connected so they don't
> end up competing with each other while they're catching back up".
> Between this and your above point, I think we probably agree - there is
> material technical complexity hiding behind a “change the consensus rules“
> option. Given it’s not a critical feature by any means, putting resources into
> fixing these issues probably isn’t worth it.
For reference, the "preferentially peer with other UASF nodes" PR for
the BIP148 client was
https://github.com/UASF/bitcoin/pull/24
List discussion was at
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014618.html
I think I'll add playing around with that and reorgs on a signet to my
todo list to see how it goes in cases other than ones that are (hopefully)
vanishingly unlikely to ever happen in practice.
Cheers,
aj
[0] In some sense, this is exactly the opposite sentiment compared to
earonesty's comment:
https://github.com/bitcoin/bitcoin/pull/10900#issuecomment-317333312
I mean, I guess could solve the unsafe-now-but-maybe-safe-later
problem generally with a signature:
-authorise-dangerous-options-key=XXXX
-lockinontimeout=taproot:YYYY
where YYYY is a signature of "dangerous:lockinontimeout=taproot" or
similar by the key XXXX, and XXXX defaults to some (multisig?) key
controlled by some bitcoin people, who'll only sign that when
there's clear evidence that it will be reasonably safe, and maybe to
"cert-transparency" or something as well. So that allows having an
option become available by publishing a signature, without having
to recompile the code. And it could still be overriden by people who
know what they're doing if the default key owners are being weird. And
maybe the "dangerous" part is enough to prevent people from randomly
cut-and-pasting it from a website into their bitcoin.conf.
I dunno. No bad ideas when brainstorming...
next prev parent reply other threads:[~2021-02-22 16:27 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
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 [this message]
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=20210222162740.mif2uygjszupizqc@erisian.com.au \
--to=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=lf-lists@mattcorallo$(echo .)com \
--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