public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Jorge Timón" <jtimon@jtimon.cc>
To: Matt Corallo <lf-lists@mattcorallo.com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Cc: Michael Folkson <michaelfolkson@gmail.com>
Subject: Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
Date: Mon, 22 Feb 2021 17:31:01 +0100	[thread overview]
Message-ID: <CABm2gDrbKdxMuKdwYh0HBXNUxhqWtq1x2oLC0Ni=dbfP8b_a7Q@mail.gmail.com> (raw)
In-Reply-To: <7B0D8EE4-19D9-4686-906C-F762F29E74D4@mattcorallo.com>

Sorry, I haven't read everything. I just want to say what I think is
the best option and why.
Let's say something like 2 years in which miners can signal activation
after which, the MUST signal it for their blocks to be valid (I think
this is LOT=true, but I don't remember what LOT stands for).
Some may argue than it's easier to move from LOT=false to LOT=true
than viceversa (I think I'm getting this right), but either way
different clients could interpret things more differently more easily
and, you know, that's really bad.
If anyone is against the consensus change itself, what they should do
is run a client in which the must is turned into a MUST NOT. Whenever
miners signal activation, blocks aren't valid so that it doesn't
happen.
That way both sides can be cleanly separated and both communities
(assuming there's a community of users opposing the change) can stick
together with their own in the same chain. That is, having only 2
chains in total if there are users opposing the change or only one if
not, but never 2 chains for people who want the change or 2 chains for
pople who don't want it.

Just my two sats, please nobody ask me "why would anyone oppose
taproot?" or anything similar. Because I'm trying to generalize here,
if we're talking about activation, I think the specifics of the change
are kind of irrelevant.

Separately: thanks to everyone who worked on taproot.


On Mon, Feb 22, 2021 at 3:00 PM Matt Corallo via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>
>
> On Feb 22, 2021, at 05:16, Anthony Towns <aj@erisian.com.au> wrote:
>
> If a lockinontimeout=true node is requesting compact blocks from a
> lockinontimeout=false node during a chainsplit in the MUST_SIGNAL phase,
> I think that could result in a ban.
>
> More importantly, nodes on both sides of the fork need to find each other.
>
>
> (If there was going to be an ongoing fork there'd be bigger things to
> worry about...)
>
>
> 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 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.
>
> Matt
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


  parent reply	other threads:[~2021-02-22 16:39 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-17 12:51 [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT) 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
2021-02-22 16:31                                     ` Jorge Timón [this message]
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='CABm2gDrbKdxMuKdwYh0HBXNUxhqWtq1x2oLC0Ni=dbfP8b_a7Q@mail.gmail.com' \
    --to=jtimon@jtimon.cc \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=lf-lists@mattcorallo.com \
    --cc=michaelfolkson@gmail.com \
    /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