[bitcoin-dev] Making the case for flag day activation of taproot

[bitcoin-dev] Making the case for flag day activation of taproot

[Chris Belcher]

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

Re: [bitcoin-dev] Making the case for flag day activation of taproot

[Vincent Truong]

[-- Attachment #1: Type: text/plain, Size: 10665 bytes --]

I must remind everyone of Mike Hearn's proposal not many years ago, which
ought to be on everyone's mind right now. "Every soft fork should be a hard
fork, and that soft forks are inherently dangerous because old nodes are
tricked to not know what the new nodes are doing" (paraphrased). Whether
taproot is dangerous is not the issue; whether old nodes should or should
not ignore new rules, is.

Flag day activation of a soft fork is basically proposing a hard fork, but
without saying or doing it at full commitment. May as well just do a flag
day hard fork.

Bitcoin Cash/Bcash has already tested for you how a market driven hard fork
should work. Bitcoin didn't die. We should be learning from the mistakes
made in those early hard forks to not repeat them when Bitcoin hard forks -
like having replay protection written before deployment.

If it's not evident within the first 6-12 blocks which fork is winning,
then the market will trade it out. Just like what happened with Bitcoin
Cash/Bcash.

Not only that, it stops the drama of Bitcoin Core devs from "being in
control" of consensus. The market will choose, you just create the safest
way for users to participate. The market is consensus. Rough consensus is
just the conversation starter.


On Thu, 4 Mar 2021, 1: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
>

[-- Attachment #2: Type: text/html, Size: 13600 bytes --]

Re: [bitcoin-dev] Making the case for flag day activation of taproot

[Eric Voskuil]

[-- Attachment #1: Type: text/plain, Size: 12258 bytes --]

Mike was wrong about a number of things, and in the end decided that Bitcoin was pointless, as people could not defend it against the state. He used this as the basis for his defense of large blocks and centralized mining. When that didn’t work out he quit, to work on centralized systems.

People can of course do what they want, but unnecessarily splitting from the existing chain reduces utility, which seems counterproductive. BCH is a good example of this.

Compatibility isn’t “dangerous”. Old nodes don’t need to know what new nodes are doing. If the person operating one needs to validate a taproot payment to himself, he would have to upgrade. Otherwise it’s of no consequence, his node is economic (relevant) only in relation to the legacy payments he receives, which he can continue to validate.

e

> On Mar 4, 2021, at 15:22, Vincent Truong via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
> 
> 
> I must remind everyone of Mike Hearn's proposal not many years ago, which ought to be on everyone's mind right now. "Every soft fork should be a hard fork, and that soft forks are inherently dangerous because old nodes are tricked to not know what the new nodes are doing" (paraphrased). Whether taproot is dangerous is not the issue; whether old nodes should or should not ignore new rules, is.
> 
> Flag day activation of a soft fork is basically proposing a hard fork, but without saying or doing it at full commitment. May as well just do a flag day hard fork.
> 
> Bitcoin Cash/Bcash has already tested for you how a market driven hard fork should work. Bitcoin didn't die. We should be learning from the mistakes made in those early hard forks to not repeat them when Bitcoin hard forks - like having replay protection written before deployment.
> 
> If it's not evident within the first 6-12 blocks which fork is winning, then the market will trade it out. Just like what happened with Bitcoin Cash/Bcash.
> 
> Not only that, it stops the drama of Bitcoin Core devs from "being in control" of consensus. The market will choose, you just create the safest way for users to participate. The market is consensus. Rough consensus is just the conversation starter.
> 
> 
>> On Thu, 4 Mar 2021, 1: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

[-- Attachment #2: Type: text/html, Size: 15075 bytes --]

Re: [bitcoin-dev] Making the case for flag day activation of taproot

[yanmaani]

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

Re: [bitcoin-dev] Making the case for flag day activation of taproot

[Chris Belcher]

It is good that social media drama can only make its own followers fork
away. In bitcoin people represent themselves, if they want certain rules
enforced they should have to actually tell their software to do that.
The problem with BIP8 is that social media drama has a incentive to
promote brinksmanship.


It is not correct to say that this will work because "nobody will
disobey Core". In reality it will work because basically everyone either
wants taproot or has no opinion about taproot.

Your argument depends heavily on the word "egregious". I've shown that
for harmful changes like censorship can be resisted by the bitcoin
community. Can you come up with an example of a bad change which won't
be resisted?


Here's another example of an easily-resisted change: A Core team that's
been compromised might do a flag-day UASF where transactions are only
confirmed if they pay a minimum of 1000 sat/vbyte in miner fee. The
community could resist this by doing a counter-UASF where a transaction
paying just 1 sat/vbyte is required to be included in the first block
after the flay day.

What alternative do you suggest? If you advocate allowing miners to
activate soft forks then that still won't protect users. Because miners
won't save users in my above example of a 1000 sat/vbyte price floor, in
fact miners would see their income greatly increased if the soft fork
was successful. So in fact the ability to do a counter-UASF is always
what actually protected users, miner protection is nothing something to
count on.



On 03/03/2021 17:30, yanmaani@cock.li wrote:
> 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

Re: [bitcoin-dev] Making the case for flag day activation of taproot

[yanmaani]

On 2021-03-03 20:48, Chris Belcher wrote:
> On 03/03/2021 17:30, yanmaani@cock.li wrote:
>> 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!
> It is good that social media drama can only make its own followers fork
> away. In bitcoin people represent themselves, if they want certain 
> rules
> enforced they should have to actually tell their software to do that.
> The problem with BIP8 is that social media drama has a incentive to
> promote brinksmanship.

Tell their software to do it, yes, but fork it? That seems like a big 
"I'm sorry Dave, I'm afraid I can't do that" moment. If I tell Bitcoin 
Core to do something, it seems like a bad thing that it would favor the 
Core devs' wishes ("Get Taproot done") over mine.

>> 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.
[...]
>> 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.

> It is not correct to say that this will work because "nobody will
> disobey Core". In reality it will work because basically everyone 
> either
> wants taproot or has no opinion about taproot.

Both can be true at the same time. This is going to work because 
basically nobody opposes Taproot. But if you did have some people 
opposing Taproot, it would still work, because nobody would want to 
disobey Core.

> Your argument depends heavily on the word "egregious". I've shown that
> for harmful changes like censorship can be resisted by the bitcoin
> community. Can you come up with an example of a bad change which won't
> be resisted?

Example 1: There is currently a specific mining pool planning to 
blacklist addresses on sanctions lists. If they were to 
convince/bribe/threaten Core to soft-fork so as to burn one specific 
UTXO worth $1, the only direct victim of that would be the holder of 
that UTXO, who loses only $1 from it.

Example 2: A soft fork to decrease the block size by 0.1%.

If we assume that the current block size is optimal and censorship is 
bad, it seems simultaneously true that
1) it would be bad to decrease the block size or to burn that UTXO
2) nobody would be wiling to fight a war over a 0.1% decrease or a $1 
loss to one guy

You might say that these are minor changes. Sure. But that's what I'm 
saying: if the change is big ("egregious") enough to seriously 
inconvenience people, they would fight it, but if it's trivial (thought 
still bad), the inertia of Core would force them to accept it.

> Here's another example of an easily-resisted change: A Core team that's
> been compromised might do a flag-day UASF where transactions are only
> confirmed if they pay a minimum of 1000 sat/vbyte in miner fee. The
> community could resist this by doing a counter-UASF where a transaction
> paying just 1 sat/vbyte is required to be included in the first block
> after the flay day.

(Nitpick: Miners would probably not support it, because less people 
would be willing to pay that fee.)

Sure, and this change would be resisted because it seriously 
inconveniences people. But what if it's just 2sat/vbyte?

>> 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.
> What alternative do you suggest? If you advocate allowing miners to
> activate soft forks then that still won't protect users. Because miners
> won't save users in my above example of a 1000 sat/vbyte price floor, 
> in
> fact miners would see their income greatly increased if the soft fork
> was successful. So in fact the ability to do a counter-UASF is always
> what actually protected users, miner protection is nothing something to
> count on.

I don't disagree. The ability to do a counter-UASF should also be added, 
if it's envisioned somebody might want to do that.

Basically, I think that Core should provide users with the tools to 
express their views and to exercise their economic power, and they could 
give them default values according to what they think best.

However, they shouldn't force people to use a forked client if they want 
to disobey them. That would be to abuse the power vested in the 
development group.

>> 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.
>> 
>> 
>>> 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]
>> 
>> 
>> 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.
>> 

>> 

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

Re: [bitcoin-dev] Making the case for flag day activation of taproot

[Russell O'Connor]

[-- Attachment #1: Type: text/plain, Size: 10899 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 13348 bytes --]

Re: [bitcoin-dev] Making the case for flag day activation of taproot

[Matt Corallo]

On 3/3/21 14:08, Russell O'Connor via bitcoin-dev wrote:
> 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.

How do you propose avoiding divergent consensus rules on the network, something which a number of commentors on this 
list have publicly committed to?

> 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.

I think this is one of the strongest arguments against a flag day activation, but, as I described in more detail in the 
thread "Straight Flag Day (Height) Taproot Activation", I'm not sure we aren't there enough already.

> In the next release, 6 months later or so, Core could then confidently deploy a BIP8 LOT=true 

Could you clarify what an acceptable timeline is, then? Six months from release of new consensus rules to activation (in 
the case of a one-year original window) seems incredibly agressive for a flag-day activation, let alone one with 
forced-signaling, which would require significantly higher level of adoption to avoid network split risk. In such a 
world, we'd probably get Taproot faster with a flag day from day one.

> 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.

That was precisely the original goal with the LOT=false movement - do something easy and avoid having to hash out all 
the technical details of a second deployment. Sadly, that's no longer tennable as a number of people are publicly 
committed to deploying LOT=true software on the network ASAP.

Matt

Re: [bitcoin-dev] Making the case for flag day activation of taproot

[Russell O'Connor]

[-- Attachment #1: Type: text/plain, Size: 6615 bytes --]

Appologies as I've rearranged your comments in my reply.

On Wed, Mar 3, 2021 at 5:14 PM Matt Corallo <lf-lists@mattcorallo.com>
wrote:

>
> On 3/3/21 14:08, Russell O'Connor via bitcoin-dev wrote:
>
> 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.
>
> I think this is one of the strongest arguments against a flag day
> activation, but, as I described in more detail in the
> thread "Straight Flag Day (Height) Taproot Activation", I'm not sure we
> aren't there enough already.
>

I agree with you.  I also think we have plenty of evidence to proceed with
taproot and could proceed with a PR for such a flag day activation.  If
there is support for it to be merged, that would be fantastic.  I think we
should proceed along these lines forthwith.

However, the existence and/or release of a flag day activation code does
not in of itself preclude concurrently developing and/or releasing a BIP8
LOT=false deployment.  Activating taproot is "idempotent" after all. We
could even do a Core release with a flag day activation while we continue
to discuss BIP8 LOT=false if that gets the ball rolling.  Certainly having
a flag day activation code merged would take a lot of pressure off further
BIP8 LOT=false work.

As Aaron noted on IRC, if the sticking point here is the MUST_SIGNAL state,
then running BIP8 LOT=false alongside a flag day activation at timeout may
be the way to go.  Once a flag day deployment is released, the LOT=true
people would have their guaranteed activation and would be less interested
in an alternative client. And without a MUST_SIGNAL state, I believe the
LOT=false deployment won't lead any hashpower that is following
standardness rules to create invalid blocks.


> > In the next release, 6 months later or so, Core could then confidently
> deploy a BIP8 LOT=true
>
> Could you clarify what an acceptable timeline is, then? Six months from
> release of new consensus rules to activation (in
> the case of a one-year original window) seems incredibly agressive for a
> flag-day activation, let alone one with
> forced-signaling, which would require significantly higher level of
> adoption to avoid network split risk. In such a
> world, we'd probably get Taproot faster with a flag day from day one.
>

Whatever timeline people are in favour of.  I think having a year or more
between the LOT=true or flag day more and the anticipated second release
date is fair myself.
That would suggest a 2-year timeout from the start to give plenty of room.

Of course, if we start with a flag day from the start then we can just do 1
year and we don't need a second deployment.

We could also do a "Let’s see what happens" with a short 3 or 4-month
deployment and still do a follow up activation if that is more agreeable.
That would give a net of about 1.5 years or so because we don't need to
anticipate the second relase date.

I'm good with whatever, and I'm happy to make more concrete suggestions if
that is necessary.  I think there exist acceptable timelines here.


> > 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.
>


> That was precisely the original goal with the LOT=false movement - do
> something easy and avoid having to hash out all
> the technical details of a second deployment. Sadly, that's no longer
> tennable as a number of people are publicly
> committed to deploying LOT=true software on the network ASAP.
>



First things last:

> 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.
>
> How do you propose avoiding divergent consensus rules on the network,
> something which a number of commentors on this
> list have publicly committed to?
>

Firstly, it is an open network.  Anyone can join and run whatever consensus
rules they want.  People have run divergent consensus rules on the network
in the past and it will continue to do so in the future.
It is troublesome when it happens in mass, but it isn't fatal.  We can't
prevent it, and we should continue working to keep the protocol robust in
the face of it.
And we certainly shouldn't be bullied by anyone who comes threatening their
own soft-fork.

Even simply doing nothing may not prevent divergent consensus from
appearing on the network.  Playing conservative isn't playing it safe
because there is nothing more conservative than doing nothing, which isn't
guaranteed to be safe in this sense.

Secondly, for the specific concern of people running BIP8 LOT=true clients,
we could start with "Let’s see what happens" with a short 3 or 4 month
signaling period.  A short enough signaling period is not "hijackable".  We
could add a longer LOCKED_IN period if there are worries about getting
enough nodes upgraded in time for activation.  I see other options as well.

I keep being told that miners are ready and willing to activate, and
taproot will probably activate in two months. All we have to do is get
something out the door that does that.  If taproot activates in two months,
great.  If it fails to activate we will learn so much in so little time.
UASF's will get to say "I told you so" without waiting a year.  Users will
get to take active, meaningful and observable steps to demonstrate their
desire for a taproot upgrade.  Very little time will be wasted, in
particular we don't have to finish debating how best to handle the unlikely
scenario where taproot doesn't activate right away for whatever reason that
is, an scenario that isn't even likely to occur.

I'm still very optimistic.  I see multiple plausible and potentially
acceptable paths towards activation still open and we don't even have to
choose only one.  I can hardly wait to look at the forthcoming PRs for
these possibilities.


> Matt
>

[-- Attachment #2: Type: text/html, Size: 8540 bytes --]

Re: [bitcoin-dev] Making the case for flag day activation of taproot

[Keagan McClelland]

[-- Attachment #1: Type: text/plain, Size: 8900 bytes --]

As one of the folks that prefers LOT=true I can certainly attest to the
fact that at least some of us would be willing to do a flag day activation
instead. As far as I'm concerned, flag day does not give a very small
percentage of the user base (5-10% of minerz) the ability to veto a change
that has broad support and is non-invasive.

However, I must question the incongruence between those who oppose LOT=true
and support a possible flag day activation. In my mind, all that LOT=true
does is concatenate a flag day activation after a LOT=false deployment,
where, as Russell noted, activation is an idempotent operation.

So that leads me to believe here that the folks who oppose LOT=true
primarily have an issue with forced signaling, which personally I don't
care about as much, not the idea of committing to a UASF from the get go.

More generally, I want to remind everyone that this is a change everyone
supports (so far). So letting the activation method kill the proposal
altogether would be tragic. If those with specific objections to various
activation methods can be clear about what those objections are, and, even
better, suggest small adjustments to various proposals on those grounds, I
think we have a far more optimistic path forward on getting Taproot
activated. Bitcoin may not have voting, but it certainly can have
compromise to come to consensus on these things. I don't think anyone in
the UASF crowd is impatient with respect to the actual guaranteed
activation timeline, what I get the sense of is a burnout on the arguments,
paired with no action. To the degree that we can make progress on coming to
an agreement that makes people comfortable, even if you don't get
everything you want, I think.

Keagan

On Thu, Mar 4, 2021 at 11:04 AM Russell O'Connor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Appologies as I've rearranged your comments in my reply.
>
> On Wed, Mar 3, 2021 at 5:14 PM Matt Corallo <lf-lists@mattcorallo.com>
> wrote:
>
>>
>> On 3/3/21 14:08, Russell O'Connor via bitcoin-dev wrote:
>>
> > 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.
>>
>> I think this is one of the strongest arguments against a flag day
>> activation, but, as I described in more detail in the
>> thread "Straight Flag Day (Height) Taproot Activation", I'm not sure we
>> aren't there enough already.
>>
>
> I agree with you.  I also think we have plenty of evidence to proceed with
> taproot and could proceed with a PR for such a flag day activation.  If
> there is support for it to be merged, that would be fantastic.  I think we
> should proceed along these lines forthwith.
>
> However, the existence and/or release of a flag day activation code does
> not in of itself preclude concurrently developing and/or releasing a BIP8
> LOT=false deployment.  Activating taproot is "idempotent" after all. We
> could even do a Core release with a flag day activation while we continue
> to discuss BIP8 LOT=false if that gets the ball rolling.  Certainly having
> a flag day activation code merged would take a lot of pressure off further
> BIP8 LOT=false work.
>
> As Aaron noted on IRC, if the sticking point here is the MUST_SIGNAL
> state, then running BIP8 LOT=false alongside a flag day activation at
> timeout may be the way to go.  Once a flag day deployment is released, the
> LOT=true people would have their guaranteed activation and would be less
> interested in an alternative client. And without a MUST_SIGNAL state, I
> believe the LOT=false deployment won't lead any hashpower that is following
> standardness rules to create invalid blocks.
>
>
>> > In the next release, 6 months later or so, Core could then confidently
>> deploy a BIP8 LOT=true
>>
>> Could you clarify what an acceptable timeline is, then? Six months from
>> release of new consensus rules to activation (in
>> the case of a one-year original window) seems incredibly agressive for a
>> flag-day activation, let alone one with
>> forced-signaling, which would require significantly higher level of
>> adoption to avoid network split risk. In such a
>> world, we'd probably get Taproot faster with a flag day from day one.
>>
>
> Whatever timeline people are in favour of.  I think having a year or more
> between the LOT=true or flag day more and the anticipated second release
> date is fair myself.
> That would suggest a 2-year timeout from the start to give plenty of room.
>
> Of course, if we start with a flag day from the start then we can just do
> 1 year and we don't need a second deployment.
>
> We could also do a "Let’s see what happens" with a short 3 or 4-month
> deployment and still do a follow up activation if that is more agreeable.
> That would give a net of about 1.5 years or so because we don't need to
> anticipate the second relase date.
>
> I'm good with whatever, and I'm happy to make more concrete suggestions if
> that is necessary.  I think there exist acceptable timelines here.
>
>
>> > 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.
>>
>
>
>> That was precisely the original goal with the LOT=false movement - do
>> something easy and avoid having to hash out all
>> the technical details of a second deployment. Sadly, that's no longer
>> tennable as a number of people are publicly
>> committed to deploying LOT=true software on the network ASAP.
>>
>
>
>
> First things last:
>
> > 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.
>>
>> How do you propose avoiding divergent consensus rules on the network,
>> something which a number of commentors on this
>> list have publicly committed to?
>>
>
> Firstly, it is an open network.  Anyone can join and run whatever
> consensus rules they want.  People have run divergent consensus rules on
> the network in the past and it will continue to do so in the future.
> It is troublesome when it happens in mass, but it isn't fatal.  We can't
> prevent it, and we should continue working to keep the protocol robust in
> the face of it.
> And we certainly shouldn't be bullied by anyone who comes threatening
> their own soft-fork.
>
> Even simply doing nothing may not prevent divergent consensus from
> appearing on the network.  Playing conservative isn't playing it safe
> because there is nothing more conservative than doing nothing, which isn't
> guaranteed to be safe in this sense.
>
> Secondly, for the specific concern of people running BIP8 LOT=true
> clients, we could start with "Let’s see what happens" with a short 3 or 4
> month signaling period.  A short enough signaling period is not
> "hijackable".  We could add a longer LOCKED_IN period if there are worries
> about getting enough nodes upgraded in time for activation.  I see other
> options as well.
>
> I keep being told that miners are ready and willing to activate, and
> taproot will probably activate in two months. All we have to do is get
> something out the door that does that.  If taproot activates in two months,
> great.  If it fails to activate we will learn so much in so little time.
> UASF's will get to say "I told you so" without waiting a year.  Users will
> get to take active, meaningful and observable steps to demonstrate their
> desire for a taproot upgrade.  Very little time will be wasted, in
> particular we don't have to finish debating how best to handle the unlikely
> scenario where taproot doesn't activate right away for whatever reason that
> is, an scenario that isn't even likely to occur.
>
> I'm still very optimistic.  I see multiple plausible and potentially
> acceptable paths towards activation still open and we don't even have to
> choose only one.  I can hardly wait to look at the forthcoming PRs for
> these possibilities.
>
>
>> Matt
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 11180 bytes --]

Re: [bitcoin-dev] Making the case for flag day activation of taproot

[Ryan Grant]

On Thu, Mar 4, 2021 at 7:32 PM Keagan McClelland via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> So that leads me to believe here that the folks who oppose LOT=true
> primarily have an issue with forced signaling, which personally I
> don't care about as much, not the idea of committing to a UASF from
> the get go.

The biggest disconnect is between two goals: modern soft-fork
activation's "Don't (needlessly) lose hashpower to un-upgraded
miners"; and UASF's must-signal strategy to prevent inaction.

  https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html

This question dives to the heart of Bitcoin's far-out future.
Of two important principles, which principle is more important:

  - to allow everyone (even miners) to operate on the contract they
    accepted when entering the system; or

  - to protect against protocol sclerosis for the project as a whole?

Do miners have a higher obligation to evaluate upgrades than economic
nodes implementing cold storage and infrequent spends?  If they do,
then so far it has been implicit.  LOT=true would make that obligation
explicit.

Re: [bitcoin-dev] Making the case for flag day activation of taproot

[Luke Dashjr]

On Friday 05 March 2021 14:51:12 Ryan Grant via bitcoin-dev wrote:
> On Thu, Mar 4, 2021 at 7:32 PM Keagan McClelland via bitcoin-dev
>
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > So that leads me to believe here that the folks who oppose LOT=true
> > primarily have an issue with forced signaling, which personally I
> > don't care about as much, not the idea of committing to a UASF from
> > the get go.
>
> The biggest disconnect is between two goals: modern soft-fork
> activation's "Don't (needlessly) lose hashpower to un-upgraded
> miners"; and UASF's must-signal strategy to prevent inaction.
>
>  
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547
>.html
>
> This question dives to the heart of Bitcoin's far-out future.
> Of two important principles, which principle is more important:
>
>   - to allow everyone (even miners) to operate on the contract they
>     accepted when entering the system; or

There was never any such a contract. Even full nodes must upgrade in a 
softfork, or they lose their security and become comparable to light wallets.

>   - to protect against protocol sclerosis for the project as a whole?

What?

> Do miners have a higher obligation to evaluate upgrades than economic
> nodes implementing cold storage and infrequent spends?  If they do,
> then so far it has been implicit.  LOT=true would make that obligation
> explicit.

Miners either make valid blocks or they don't.
The only thing they "need" to evaluate is the market for their work.

Luke

Re: [bitcoin-dev] Making the case for flag day activation of taproot

[Matt Corallo]

Replies inline. Several sections removed, where I basically agree.

On 3/4/21 08:47, Russell O'Connor wrote:
> Appologies as I've rearranged your comments in my reply.
> I agree with you.  I also think we have plenty of evidence to proceed with taproot and could proceed with a PR for such 
> a flag day activation.  If there is support for it to be merged, that would be fantastic.  I think we should proceed 
> along these lines forthwith.
> 
> However, the existence and/or release of a flag day activation code does not in of itself preclude concurrently 
> developing and/or releasing a BIP8 LOT=false deployment.  Activating taproot is "idempotent" after all. We could even do 
> a Core release with a flag day activation while we continue to discuss BIP8 LOT=false if that gets the ball rolling.  
> Certainly having a flag day activation code merged would take a lot of pressure off further BIP8 LOT=false work.

Hmm, while this is certainly true at a technical level, it adds a lot of complexity both in terms of discussion, and for 
users - "I already upgraded to Taproot, why did I just see a fork with an invalid Taproot spend?".

> As Aaron noted on IRC, if the sticking point here is the MUST_SIGNAL state, then running BIP8 LOT=false alongside a flag 
> day activation at timeout may be the way to go.  Once a flag day deployment is released, the LOT=true people would have 
> their guaranteed activation and would be less interested in an alternative client. And without a MUST_SIGNAL state, I 
> believe the LOT=false deployment won't lead any hashpower that is following standardness rules to create invalid blocks.

This is indeed a significant improvement over BIP 8 in my opinion. However, as I pointed out on a Reddit discussion with 
Aaron, I'm still incredibly worried about users pushing for some UASF-style forced-signaling guerilla faster-activation. 
It may absolutely be the case that Taproot activates quickly or that such users are a tiny minority of transacting. 
However, as we saw with BIP 148/UASF, even a tiny minority of transacting users can set the tone and claim victory over 
how a soft-fork activates. I worry that even your approach here runs the risk of yet further normalization of consensus 
rule diversity on the network.

Maybe my worry is overblown, and I'm certainly not going to try to solely stand in the way on this one, but now that 
we're stuck in yet another overblown debate, we might as well take it as an opportunity to reinforce the idea that 
consensus rule diversity runs the risk of consensus failure, and isn't a reasonable risk.
> 
>      > 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.
> 
>     How do you propose avoiding divergent consensus rules on the network, something which a number of commentors on this
>     list have publicly committed to?
> 
> 
> Firstly, it is an open network.  Anyone can join and run whatever consensus rules they want.  People have run divergent 
> consensus rules on the network in the past and it will continue to do so in the future.
> It is troublesome when it happens in mass, but it isn't fatal.  We can't prevent it, and we should continue working to 
> keep the protocol robust in the face of it.
> And we certainly shouldn't be bullied by anyone who comes threatening their own soft-fork.

Apologies. I should have phrased my comment better. My worry, at a broad level is that
(a) people have taken the events around the Segwit BIP 148 UASF to mean that a very small minority of users can (and 
maybe should) push consensus rules through threats of breaking consensus and
(b) there is a very vocal group today which is reinforcing this belief by ignoring the complex context around Segwit and 
behaving similarly with regards to Taproot.

Indeed, there is nothing we can, or should, do to actively prevent people from running their own software which 
interprets Bitcoin's consensus rules in...creative ways. But that isn't to say there is no use worrying about it. 95% of 
Bitcoin users aren't aware that this debate is even happening. Of the remaining 5%, 90% haven't had the time to research 
and think deeply enough to form an opinion. Our responsibility is to the 99.5% of users.

Sure, individuals running different consensus rules won't cause immediate harm to others, but the net effect of many 
users doing so and especially the community normalizing such behavior very significantly can. Ill-informed transactors 
running such software (including wallet providers with users who were unaware of the events) can be screwed out of their 
Bitcoin. This outcome very well could have occurred in the case of the BIP 148 UASF, and repeating the same pattern many 
times will not help to de-risk that.

> Even simply doing nothing may not prevent divergent consensus from appearing on the network.  Playing conservative isn't 
> playing it safe because there is nothing more conservative than doing nothing, which isn't guaranteed to be safe in this 
> sense.

Indeed. The obvious most conservative action is not activating Taproot at all. Obviously this is unlikely to solve the 
issue :).

> Secondly, for the specific concern of people running BIP8 LOT=true clients, we could start with "Let’s see what happens" 
> with a short 3 or 4 month signaling period.  A short enough signaling period is not "hijackable".  We could add a longer 
> LOCKED_IN period if there are worries about getting enough nodes upgraded in time for activation.  I see other options 
> as well.

Potentially indeed. Though I'm not so sure that several months represents a period that is not "hijackable", given the 
speed at which someone can hack together naive activation code.

> I keep being told that miners are ready and willing to activate, and taproot will probably activate in two months. All 
> we have to do is get something out the door that does that.  If taproot activates in two months, great.  If it fails to 
> activate we will learn so much in so little time.  UASF's will get to say "I told you so" without waiting a year.  Users 
> will get to take active, meaningful and observable steps to demonstrate their desire for a taproot upgrade.  Very little 
> time will be wasted, in particular we don't have to finish debating how best to handle the unlikely scenario where 
> taproot doesn't activate right away for whatever reason that is, an scenario that isn't even likely to occur.

Indeed, I've always suggested a miner activation window first to "learn something" about the state of it. However, I do 
think we've passed the point where that should be a chief concern. The strength and diversity of public statements in 
support of Taproot as a change to the network is rather overwhelming.

> I'm still very optimistic.  I see multiple plausible and potentially acceptable paths towards activation still open and 
> we don't even have to choose only one.  I can hardly wait to look at the forthcoming PRs for these possibilities.

I agree :).

Re: [bitcoin-dev] Making the case for flag day activation of taproot

[Anthony Towns]

On Wed, Mar 03, 2021 at 02:08:21PM -0500, Russell O'Connor via bitcoin-dev wrote:
> 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.

If everyone started with lot=false, that would be true -- that was how
segwit then BIP148/BIP91 worked, and was at least how I had been assuming
people were going to make use of the new improved BIP8.

But it seems more likely that when activation starts, even if many
people run lot=false, many other people will run lot=true: see Luke's
arguments on this list [0], Rusty's campaign for a lot=true option [1],
the ##uasf channel (initial topic: Development of a Taproot activation
implementation with default LOT=true) [2], or Samson's hat designs [3].

[0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018498.html
[1] https://rusty.ozlabs.org/?p=628
    https://gist.github.com/michaelfolkson/92899f27f1ab30aa2ebee82314f8fe7f#gistcomment-3667311
[2] http://gnusha.org/uasf/
[3] https://twitter.com/Excellion/status/1363751091460956167

With lot=false and lot=true nodes active on the network, a chain split
occurs if the activation is blocked: perhaps that might happen for good
reasons, eg because there are implementation bugs found after activation
settings are merged but prior to activation locking in, or perhaps for
neutral or bad reasons that cause miners to be opposed.

In the event of a huge conflict or emergency as bad as or worse than
occurred with segwit, a chain split might well be the lesser evil
compared to the activation being blocked or delayed substantially;
but as default scenario for every consensus change, before we know if
someone might find a problem while there's still time to back out, and
before we know if there is going to be a huge conflict? It doesn't seem
as focussed on safety as I'd expect from bitcoin.

> 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.

BIP8/lot=true is great for the situation we found ourselves in with
BIP91/BIP148: there's an activation underway, that is being unexpectedly
opposed, we want to ensure it activates, *and* we don't want to have
everyone have to do a new round of software upgrades.

But if we're able to calmly put out a new release with new activation
parameters, with enough time before it takes effect that everyone can
reasonably upgrade to it, that's a pretty different situation.

First, since we're giving everyone time to upgrade, it can be a clean
secondary deployment -- there's no need to try to drag the original
lot=false users along -- we're giving everyone time to upgrade, and
everyone includes them.

Second, lot=true implies we're doing some unsignalled consensus change
anyway -- blocks would be considered invalid if they don't signal for
activation as of some height, with no prior on-chain signalling that
that rule change has occurred. So if we're allowing that, there's no
principle that requires signalling to lock in the change we're actually
trying to activate.

So at that point why not simply reverse the burden of proof entirely? Run
an initial "speedy trial" type event that allows fast activation via miner
enforcement prior to everyone having upgraded; and if that fails but there
haven't been valid reasonable objections to activation identified, run
a secondary activation attempt that instead of requiring 90% signalling
to activate, requires 90% signalling to *fail*.

Miners not upgrading is then not a blocker, and even if a few miners are
buggy and signal accidently, that doesn't cause a risk to them of having
their blocks dropped, or to the network of having the upgrade blocked.

If there are good reasons to object to the fork being activated that are
discovered/revealed (very) late, this also provides an opportunity to
cleanly cancel the activation by convincing miners that the activation
is undesirable and having them agree to signal for cancellation (via
BIP-91 style coordination or even BIP-148 style mandatory signalling, eg).

And, on the other hand, if 90% of miners are opposed to a soft fork for
some selfish or bad reason, with that much hashpower they could easily do
a 51% attack on the network after activation to prevent any new features
being used, so cancelling activation in that case is probably not worse
in practice than it would be continue with it despite the opposition.

I think a state machine along the lines of:

  DEFINED - for 6 months after code release
  STARTED - exactly 1 period
    FAILED - if sufficient signalling occurs
  DELAYED - 6 months
  LOCKED_IN - exactly 1 period
  ACTIVE

would work fine for an if-at-first-you-don't-succeed approach to
deployment along the above lines.

That seems to me to have a lot of desirable properties:

 - a minority of hashpower can't block activation

 - miners don't have to do anything and don't have to worry about
   their blocks getting orphaned
   
 - devs aren't making any final decisions on consensus changes,
   even if everyone's committed to running the same codebase
   (unlike when merging either lot=true or flag day activations)

 - there's no need to run different clients, or carefully configure your
   node to stay in consensus

 - if economic actors want to influence activation by setting up
   markets, they have a single signalling period to focus on, with 6
   months lead time to set everything up and stabilise price discovery,
   and a fairly definite endpoint and clear result for closing out
   everyone's positions, whichever outcome occurs

 - there's no need/encouragement to use the machine vetting your business
   income as leverage to force/prevent changes to bitcoin consensus;
   configuring your node to not follow the most work chain is only
   needed when both devs and miners are getting it wrong, *and* market
   incentives haven't been enough to correct things

The main drawback is that it doesn't allow faster activation with miner
support; even with a speedy trial first, it's just a boolean: did miners
indicate they've upgraded quickly enough to hit the early activation
or not?

Cheers,
aj

Re: [bitcoin-dev] Making the case for flag day activation of taproot

[Luke Kenneth Casson Leighton]

would it help by first setting a regular period of e.g. 6 months when
only at that time would consensus rules ever be changed?  not, "6
months from now taproot will be introduced', a rule, "*any* consensus
change regardless of what they are (including NO change) will *ONLY*
be made at regular interval period X months".

this stops dead efforts by bots to announce "consensus! rules! are
changing!" because if it's not at the exact time-period it's clearly
bullshit.

l.