public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: yanmaani@cock•li
To: Chris Belcher <belcher@riseup•net>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Making the case for flag day activation of taproot
Date: Wed, 03 Mar 2021 17:30:20 +0000	[thread overview]
Message-ID: <85745a38e4464541d6357408fae1cfed@cock.li> (raw)
In-Reply-To: <3286a7eb-9deb-77d6-4527-58e0c5882ae2@riseup.net>

On 2021-03-03 14:39, Chris Belcher via bitcoin-dev wrote:
> Enter flag day activation. With a flag day there can be no
> brinksmanship. A social media blitz cant do anything except have its 
> own
> followers fork away. Crucially, miner signalling cant be used to change
> the activation date for nodes that didn't choose to and just passively
> follow signalling. Changing the activation date requires all those 
> users
> to actually run different node software.

Is that supposed to be a good thing? "We should do X because it'll work" 
doesn't prove X is actually good. These things can be evil, but they can 
also be legitimate opposition to a change. Taking away the power of a 
"social media blitz" is not guaranteed to be a good thing!

> What if one day the Core developer team uses the flag
> day method to do something bad? The bitcoin user
> community who wants to resist this can create their own
> counter-soft-fork full node. This forces a chain
> split. The real bitcoin which most people follow will be
> the chain without censorship.

[edited for brevity]

That will only work for really egregious changes. In practice, most 
people will trust Core on all other (non-egregious) decisions, because 
of the inertia inherent in disobeying them.

What you suggest may be an efficient way to ram taproot through, but is 
it inherently good? Nothing is free. This seems like de-facto forcing 
people to go along with you, because you're convinced you're right. In 
this case, you are, but you'd be convinced you'd be right even if you 
weren't so.

You're right in suggesting that it will work, but the reason why it will 
work is because nobody wants to disobey Core. It seems immoral to 
exploit this fact.

At least you shouldn't hard-code it and require dissenters to fork away. 
I exhort you to consider making all this controversial stuff settings 
that can be changed by RPC command or command-line flag; set the default 
value sure, but requiring a fork to change it is, in my opinion, 
oppressive.

(Also consider some compromise, such as ">95% miner support before flag 
day or >33% on flag day")

Best wishes
Yanmaani


  parent reply	other threads:[~2021-03-03 17:30 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-03 14:39 Chris Belcher
2021-03-03 16:19 ` Vincent Truong
2021-03-04 23:45   ` Eric Voskuil
2021-03-03 17:30 ` yanmaani [this message]
2021-03-03 20:48   ` Chris Belcher
2021-03-03 21:39     ` yanmaani
2021-03-03 19:08 ` Russell O'Connor
2021-03-03 22:14   ` Matt Corallo
2021-03-04 13:47     ` Russell O'Connor
2021-03-04 18:23       ` Keagan McClelland
2021-03-05 14:51         ` Ryan Grant
2021-03-05 18:17           ` Luke Dashjr
2021-03-06 17:57       ` Matt Corallo
2021-03-29  9:17   ` Anthony Towns
     [not found] <mailman.66954.1614808879.32591.bitcoin-dev@lists.linuxfoundation.org>
2021-03-03 22:12 ` Luke Kenneth Casson Leighton

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=85745a38e4464541d6357408fae1cfed@cock.li \
    --to=yanmaani@cock$(echo .)li \
    --cc=belcher@riseup$(echo .)net \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    /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