From: Chris Belcher <belcher@riseup•net>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: [bitcoin-dev] Making the case for flag day activation of taproot
Date: Wed, 3 Mar 2021 14:39:23 +0000 [thread overview]
Message-ID: <3286a7eb-9deb-77d6-4527-58e0c5882ae2@riseup.net> (raw)
The bitcoin world is close to total gridlock on the question of how to
activate taproot. There's no agreement on activation[1][2], and if an
agreement isn't reached then nothing happens. That would be really
terrible because we'd miss out on the benefits of taproot and
potentially other future soft forks.
A major problem with BIP8 is that it would result to a situation where
different parts of the bitcoin ecosystem run different consensus rules.
Some people will run LOT=true and others LOT=false. Worst of all, it
becomes vulnerable to a twitter/reddit/social media blitz which could
attempt to move the date of miner activation around.
Twitter and reddit drama provide a perfect cover for social attacks on
bitcoin.
Forced signalling leads to brinksmanship. Where two or more sides
(backed up by social media drama) enter into a game of chicken with
deployed nodes. If one of them doesn't concede then we get a damaging
chain split. And the $1 trillion in value that the bitcoin network
protects is put at risk. From the point of view of a miner or big
exchange stuck in the middle, if they look at the ecosystem of twitter
and reddit (especially if you think about all the problems with bots and
sockpuppets) they have no idea which consensus rules they should
actually follow and exactly what date they take effect. Miners,
exchanges, merchants and the rest of the ecosystem exist to serve their
customers and users, and trouble happens when they don't know what their
customers really want. Social media attacks are not just a theoretical
concern; back during the block size drama, the bitcoin reddits were
targetted by bots, sockpuppets and brigading[3].
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.
Flag day activation works simply: we choose a block height and after
that block height the new taproot rules become enforced.
Supporters of the permissionless, "users rule" approach of LOT=true
should be happy because it completely takes miners out of activation.
Supporters of the safe, conservative approach of LOT=false can be made
happy with a few ways of derisking:
* Getting mining pools, businesses and users to look at the code and ask
if they (a) think its either neutral or good for their business or use
case and (b) they believe others view it similarly and that the
consensus changes proposed have a good social consensus around them.
* Setting the flag day far in the future (18 months or 2 years in the
original proposal[3]).
== What if flag day activation is used maliciously? ==
What if one day the Core developer team is co-opted and uses the flag
day method to do something bad? For example, a soft fork where sending
to certain blacklisted addresses is not allowed. The bitcoin user
community who wants to resist this can create their own
counter-soft-fork full node, where the first block after the flag day
MUST pay to one of those addresses on the blacklist. This forces a chain
split between the censorship rules and the no-censorship rules, and its
pretty obvious that the real bitcoin which most people follow will be
the chain without censorship.
For example, if a group of users didn't agree with taproot then they
could create their own counter-flag-day-activation which requires that a
transaction is included that does an invalid-spend from a taproot output
in the first block after the flag day height.
This is always possible with any user activated soft fork. In BIP8
LOT=true it could be done by rejecting block headers with certain
version bits signalled.
== But it will take so long! ==
We seem to be at a deadlock now. This will take less time than any other
method, because other methods might never happen. BIP8 is dead and from
what I see there's no other credible plan.
We've already waited years for taproot. I remember listening to talks
about bitcoin from 2015 of people discussing Schnorr signatures. And
given how slow segwit and p2sh adoption were its pretty likely that
we'll waiting a while for taproot to be actually adopted.
== A social media blitz could still try to activate it early ==
The brinksmanship only works because miner signalling can make many
other nodes activate early, even if those other nodes didn't do
anything. There can't be a game of chicken that puts the bitcoin network
at risk.
If a group of people did adopt alternative node software which has a
shorter flag day, they actually have a risk of slow blocks. Because they
cant trick or force any other nodes to come along with them, they are
likely to only have a small economy and therefore would lose a lot of
hashrate. Imagine trading bitcoins for cash in person and instead of
waiting 10 minutes for a confirmation you have to wait 3 hours because
the blocks are slow.
Also, the argument for downloading and running a different software only
to speed up activation is pretty weak. Taproot would activate in ~18
months, so why are you so impatient that you need it in 6 months? And
risk slow blocks for you while doing so? The big difference with BIP148
the segwit UASF, is that people *had to* run some other software
otherwise they would get *no soft fork at all*.
== Without miner signalling how do we know the new rules are even
activated? ==
When did you see miners signalling their support for the inflation schedule?
Bitcoin's rules are enforced by wallets backed by full nodes. You'll
always know if your own full node is enforcing the new rules. The thing
that matters isnt miner signalling but your own full node, and the nodes
of those you trade with.
Flag day activation is quite similar to the way block reward halvenings
work. At and after block height 630000 miners are only allowed to create
6.25 BTC rather than 12.5 BTC. Everyone knows that if miners continued
to create 12.5 BTC or more they would be unable to sell or spend those
coins anywhere.
In 2017 when segwit was being activated people created a huge list of
various bitcoin companies, merchants and wallets:
https://web.archive.org/web/20171228111943/https://bitcoincore.org/en/segwit_adoption/
Looking at that list, you would know that if someone stole coins from a
segwit address they would be unable to deposit them in many exchanges
and merchants: Bitrefill, Bitstamp, Kraken, Localbitcoins, Paxful,
Vaultoro, HitBTC, etc.
Then what happened is only a month after S2X was beaten this guy moved
40000 BTC to a segwit address, confident about the power of the network
to protect his coins.
https://old.reddit.com/r/Bitcoin/comments/7tcmi4/bitcointalks_famous_user_loaded_moved_his_40k_btc/
If there's ever any doubt about flag day activation we can always draw
up a similar list, although if there's broad consensus about it then
there's no reason why bitcoin businesses wouldn't upgrade to the latest
Core, like they did with every other previous soft fork.
== This gives the impression that Core developers control the protocol ==
This objection has a mirror image argument: BIP8 with LOT=false gives
the impression that miners control the protocol(!)
Eventually some group has to make a decision. We will ask the bitcoin
economy and users what they think of flag day activation. It's pretty
clear that nobody seriously objects to taproot, and as described above
if Core developers did something evil the community could resist it with
a counter-flag-day-activation.
== TL;DR ==
I believe flag day activation is the way forward. It should answer all
the objections and risks which make other methods too controversial.
Let's go ahead and bring taproot to bitcoin!
== References ==
[1] -
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018498.html
luke-jr posts saying LOT=false in his view reintroduces a bug, he
compares it to introducing an inflation bug and just hoping that miners
will not exploit it.
[2] -
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018425.html
This whole thread has many people disagreeing with LOT=true
[3] -
https://old.reddit.com/r/Bitcoin/comments/4biob5/research_into_instantaneous_vote_behavior_in/
https://old.reddit.com/r/Bitcoin/comments/3v04pd/can_we_please_have_a_civil_discussion_about/cxjnz1d/?context=1
https://old.reddit.com/r/Bitcoin/comments/41ykkt/members_trying_to_destroy_bitcoin_on_this_thread/cz6ccka/?context=3
[4] -
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018495.html
Matt Corallo's flag day activation proposal
next reply other threads:[~2021-03-03 14:39 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-03 14:39 Chris Belcher [this message]
2021-03-03 16:19 ` Vincent Truong
2021-03-04 23:45 ` Eric Voskuil
2021-03-03 17:30 ` yanmaani
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=3286a7eb-9deb-77d6-4527-58e0c5882ae2@riseup.net \
--to=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