Taproot proposal

[acquafredda]

Is it not amusing to read Taproot related news on Coindesk's main page? Interesting recap for the non-technical fellows like myself about the latest dev meeting on taproot and its activation.
https://www.coindesk.com/taproot-bitcoin-upgrade-activation-update

The chain split scenario that willcl_ark described is basically the bogeyman everyone wants to avoid here. The fear is that BIP8 (true) requires 100% of hashrate to signal for the upgrade after the Taproot activation deadline ends. Thus, if enough users went this route at the same time that others use BIP8 (false) for non-forced activation (which only requires 95% of hashrate), the two different code versions may create two incompatible histories of Bitcoin’s transaction ledger.

This part was the most interesting and I do hope we will not have to see such a detrimental scenario.

[nutildah]

Is it not amusing to read Taproot related news on Coindesk's main page? Interesting recap for the non-technical fellows like myself about the latest dev meeting on taproot and its activation.
https://www.coindesk.com/taproot-bitcoin-upgrade-activation-update

The chain split scenario that willcl_ark described is basically the bogeyman everyone wants to avoid here. The fear is that BIP8 (true) requires 100% of hashrate to signal for the upgrade after the Taproot activation deadline ends. Thus, if enough users went this route at the same time that others use BIP8 (false) for non-forced activation (which only requires 95% of hashrate), the two different code versions may create two incompatible histories of Bitcoin’s transaction ledger.

This part was the most interesting and I do hope we will not have to see such a detrimental scenario.

Part of what got decided was to use BIP 8 instead BIP 9 -- I tried to understand what the advantage was and I guess its because they don't want a repeat of the activation controversy brought on by segwit? I'd be grateful if somebody could explain the difference between the two as I think I'm missing the significance. Thanks in advance.

[Wind_FURY]

Is it not amusing to read Taproot related news on Coindesk's main page? Interesting recap for the non-technical fellows like myself about the latest dev meeting on taproot and its activation.
https://www.coindesk.com/taproot-bitcoin-upgrade-activation-update

The chain split scenario that willcl_ark described is basically the bogeyman everyone wants to avoid here. The fear is that BIP8 (true) requires 100% of hashrate to signal for the upgrade after the Taproot activation deadline ends. Thus, if enough users went this route at the same time that others use BIP8 (false) for non-forced activation (which only requires 95% of hashrate), the two different code versions may create two incompatible histories of Bitcoin’s transaction ledger.

This part was the most interesting and I do hope we will not have to see such a detrimental scenario.

Part of what got decided was to use BIP 8 instead BIP 9 -- I tried to understand what the advantage was and I guess its because they don't want a repeat of the activation controversy brought on by segwit? I'd be grateful if somebody could explain the difference between the two as I think I'm missing the significance. Thanks in advance.

During 2017, miner-signalling for activation was used as a political tool to hostage/stop the network from doing an upgrade that the community wanted. BIP8/UASF is a method of activation wherein the full nodes decide, not the miners. The miners simply follow.

[NotATether]

Part of what got decided was to use BIP 8 instead BIP 9 -- I tried to understand what the advantage was and I guess its because they don't want a repeat of the activation controversy brought on by segwit? I'd be grateful if somebody could explain the difference between the two as I think I'm missing the significance. Thanks in advance.

BIP8 is for activating changes by block height, so that the new rules apply only after a specific block has been mined. It is better than using BIP9 which also activates some delay after a specific block number but the version bit for it expires and can be reused some time, usually a year, after its activation where they assume everyone has moved to that fork.

The problem related to segwit's activation were that there were a bunch of miners/nodes who did not follow through this activation so this bit might have expired and be used for something else without everyone fully following it. There were special BIPs made for segwit activation just to address this problem (BIP91).

[Wind_FURY]

Here’s a good Bitcoin Magazine explanation about BIP9 and BIP8, the differences, and why BIP8 COULD be better for soft fork protocol upgrades. It’s written by respected Bitcoiner, Aaron Van Wirdum.

Read it, before believing the trolls who say that it’s the miners that enforce the rules.

https://bitcoinmagazine.com/articles/bip-8-bip-9-or-modern-soft-fork-activation-how-bitcoin-could-upgrade-next

BIP 8 was an early alternative for BIP 9, proposed by BIP 148 author Shaolinfry and Bitcoin Knots and Bitcoin Core contributor Luke-jr. It initially resembled BIP 9, but with one crucial difference: instead of the upgrade failing after a year of insufficient hash power support, it would do the exact opposite and activate the soft fork at that point in time. Similar to a flag day, all upgraded nodes would from then on start enforcing the new rules. Miners who’d still have failed to upgrade would risk mining blocks that upgraded miners and users would reject.

The main idea behind BIP 8 is that — assuming of course that users upgrade — miners can’t block the soft fork and therefore can’t use this leverage to their benefit. They can speed activation up and help coordinate a smooth protocol upgrade, but the upgrade will eventually happen even if they don’t activate it themselves.

[Carlton Banks]

I'd be grateful if somebody could explain the difference between the two as I think I'm missing the significance.

1. BIP8 uses blockheight, as opposed to timestamp. This is so that the fork can still go ahead if:

• an activation is at the "locked-in" stage (i.e. block signalling is above the threshold)
• ...but the _overall_ hashrate is falling (i.e. the necessary 2016 blocks of lock-in won't occur before the timestamp when the 12 month activation period expires)

BIP8 solves that problem by not using 12 timestamped months, but 12 months of blocks (which comes with a different trade-off: it's unlikely to be 12 actual months, and for the taproot softfork, will likely be faster, due to continuing hashrate growth). The 12 months part is just a convention, it could've been more or less (and may be in future), I think 12 was chosen simply because the segwit and CSV softforks also aloted 12 months.

2. BIP8 has a "lock-in on timeout" parameter

This means that the fork activates regardless of miner signalling level at the point the activation period expires (12 months in this case).


The continuing discussion on activation for the taproot fork revolves around whether Bitcoin 0.21.1 should be released with auto lock-in (or "LOT") set as true or false, but also whether LOT can be set as user configurable (like an enforcing version of people putting "uasf" in their user agent string during segwit activation). IMO, 0.21.1 should be shipped with LOT=true, but I understand the arguments against also. At the least, it should be possible to set in the config file.

[xmready]

[gmaxwell]

xmready, why do you keep posting that image?

[xmready]

xmready, why do you keep posting that image?

Excited to see how many nodes are running 0.21.0

[gmaxwell]

Excited to see how many nodes are running 0.21.0

Which has what to do with this thread?

[Charles-Tim]

Bitcoin Taproot Upgrade Nailed Down for July, but Some Finer Details Still Aren’t Finalized. A release date and activation timeline are set for Bitcoin’s Taproot upgrade, but developers and other stakeholders are still debating the best method to coordinate Bitcoin’s biggest upgrade since SegWit.

Per a public IRC chat discussion, the code for the fully primed-and-ready Taproot upgrade will be deployed sometime between March 17 and March 31 (or April if necessary), but the actual signaling that kick-starts the activation process probably won’t start until July.

If everything goes as planned, then Bitcoin’s “economic majority” (miners and node operators who run Bitcoin’s code) could update within two weeks of the signaling period’s start. Come August 2022, Taproot’s activation period will reach its timeoutheight and signaling will end.

With a date set for the end of March and the bulk of the activation parameters chosen in BIP8, the final question to answer for Taproot’s deployment is whether or not to include the “user activated soft fork” measure from the get-go or not.

I was excited to know taproot activation is coming soon, which will be this year. But, there is a question in the link that 'what happens if the mining pools don’t signal to activate Taproot?

Taproot will ship by BIP8 in late March and activation is slated for July, so this question will have to be answered within the month.

https://www.coindesk.com/bitcoin-taproot-upgrade-july-finer-details-not-finalized



 

[xmready]

Excited to see how many nodes are running 0.21.0

Which has what to do with this thread?

Doesn't 0.21.0 contain the code for Taproot?

[Charles-Tim]

Doesn't 0.21.0 contain the code for Taproot?

This thread is about Taproot implementation, Taproot was introduced into Bitcoin core in October 2020, but not yet implemented as the implementation is a gradual process. On December 01, 2020, Bitcoin Core version 0.21.0 was released in which Taproot's code was  available for testing. If you scroll up, you will see a post where fillippone posted about it the day Bitcoin Core 0.21.0 was available.

[gmaxwell]

Doesn't 0.21.0 contain the code for Taproot?

Not in a meaningful sense.

When new consensus changes are added to bitcoin they are added in advance, completely deactivated and inert.  Later a version will be produced that doesn't change anything except arming the activation.

This avoids the risk that activation will be interrupted by unrelated issues in a new version.  It also gives more time for developers to test the fully integrated version and reduced risk that issues introduced by merging will go undetected.

So 0.21.0 doesn't have taproot support and will continue to not have any taproot support even after taproot activates.

[xmready]

Not in a meaningful sense.

When new consensus changes are added to bitcoin they are added in advance, completely deactivated and inert.  Later a version will be produced that doesn't change anything except arming the activation.

This avoids the risk that activation will be interrupted by unrelated issues in a new version.  It also gives more time for developers to test the fully integrated version and reduced risk that issues introduced by merging will go undetected.

So 0.21.0 doesn't have taproot support and will continue to not have any taproot support even after taproot activates.

Thanks! Does activation just mean a node is running 0.21.1 or do they have to take extra steps after the the upgrade to 0.21.1?

[Carlton Banks]

Does activation just mean a node is running 0.21.1 or do they have to take extra steps after the the upgrade to 0.21.1?

Put simply...

Either:

• Miners activate the fork. This happens when a certain % of miners are making blocks with a special "taproot ready" flag embedded in their mined blocks. This % of blocks must continue for ~2 weeks (for 2016 blocks)
• Users activate the fork. This happens when the timeframe for activating the fork expires

It's a little more complicated than though. Not much.

As of yet, the % for triggering the 2016 block lock-in stage hasn't been decided. Suggested figures are 90% or 95% of blocks (95% was used for some recent fork activations). The overall timeframe is also not exactly decided, but 1 year (measured in blocks...) seems to be a popular suggestion.

[xmready]

a special "taproot ready" flag embedded in their mined blocks

Is this flag a default behavior of 0.21.1 or do they set the flag manually?

[NotATether]

a special "taproot ready" flag embedded in their mined blocks

Is this flag a default behavior of 0.21.1 or do they set the flag manually?

They have to set it manually and Bitcoin Core doesn't set any flags of blocks on its own. Miners use the submitblock RPC call with the flag set in the block they submit.

There probably won't be a 0.21.1. There's a migration[1] scheduled on Github that will transition from 0.21.0 directly to 22.0. It's named that instead of 0.22.0.

[1]: https://github.com/bitcoin/bitcoin/issues/20851

[gmaxwell]

There probably won't be a 0.21.1. There's a migration[1] scheduled on Github that will transition from 0.21.0 directly to 22.0. It's named that instead of 0.22.0.

No, you're confused.  The next major version after 0.21 will be 22, but consensus changes are not activated in major releases (as they contain lots of extra features that might make some users unable to upgrade or force them to downgrade).


Development works like this:


0.19.0 --> 0.20.0 --> 0.21.0 --> 22.0 --> ...
     \          \          \
     |->0.19.1  |-> 0.20.1 |-> 0.21.1
     |->0.19.2  |-> 0.20.2 ...
     |->0.19.3  ...
     ...


So the minor releases are all forked off an earlier copy of the software and have fixes back ported to them.

The post you were seeing was discussing dropping the "0." in the master branch.

[Carlton Banks]

FYI, lukejr regrets adding LOT to BIP 8