While I support essentially any proposed taproot activation method, including a flag day activation, I think it is premature to call BIP8 dead.
Even today, I still think that starting with BIP8 LOT=false is, generally speaking, considered a reasonably safe activation method in the sense that I think it will be widely considered as a "not wholly unacceptable" approach to activation. After a normal and successful Core update with LOT=false, we will have more data showing broad community support for the taproot upgrade in hand. In the next release, 6 months later or so, Core could then confidently deploy a BIP8 LOT=true client, should it prove to be necessary. A second Core deployment of LOT=true would mitigate some of the concerns with LOT=false, but still provide a period beforehand to objective actions taken by the community in support of taproot. We don't even have to have agreement today on a second deployment of LOT=true after 6 months to start the process of a LOT=false deployment. The later deployment will almost certainly be moot, and we will have 6 months to spend debating the LOT=true deployment versus doing a flag day activation or something else. I don't think we need to start self-sabotaging our efforts to get taproot activated this year just yet. Let's cherry-pick the commits of PR #19573 to split it up into non-MUST_SIGNAL and MUST_SIGNAL components, and get some reviews on that first. Then afterwards we can decide if BIP8 is dead or not. On Wed, Mar 3, 2021 at 9:39 AM Chris Belcher via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 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 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
