acquafredda
Legendary
Offline
Activity: 1316
Merit: 1481
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 04, 2021, 05:26:35 PM Merited by fillippone (2) |
|
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-updateThe 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
Legendary
Offline
Activity: 3080
Merit: 8289
Happy 10th Birthday to Dogeparty!
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 04, 2021, 09:58:40 PM |
|
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-updateThe 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
Legendary
Offline
Activity: 3010
Merit: 1878
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 05, 2021, 12:52:13 PM |
|
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-updateThe 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.
|
| .SHUFFLE.COM.. | ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ | ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ | . ...Next Generation Crypto Casino... |
|
|
|
NotATether
Legendary
Offline
Activity: 1694
Merit: 7173
In memory of o_e_l_e_o
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 06, 2021, 05:52:54 AM |
|
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
Legendary
Offline
Activity: 3010
Merit: 1878
|
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.
|
| .SHUFFLE.COM.. | ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ | ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ | . ...Next Generation Crypto Casino... |
|
|
|
Carlton Banks
Legendary
Offline
Activity: 3430
Merit: 3080
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 06, 2021, 10:26:03 AM |
|
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" parameterThis 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.
|
Vires in numeris
|
|
|
xmready
Copper Member
Jr. Member
Offline
Activity: 37
Merit: 14
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 17, 2021, 04:49:02 AM |
|
|
|
|
|
gmaxwell (OP)
Moderator
Legendary
Offline
Activity: 4228
Merit: 8644
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 17, 2021, 05:20:24 AM |
|
xmready, why do you keep posting that image?
|
|
|
|
xmready
Copper Member
Jr. Member
Offline
Activity: 37
Merit: 14
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 18, 2021, 08:00:41 AM |
|
xmready, why do you keep posting that image?
Excited to see how many nodes are running 0.21.0
|
|
|
|
gmaxwell (OP)
Moderator
Legendary
Offline
Activity: 4228
Merit: 8644
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 18, 2021, 08:48:32 AM |
|
Excited to see how many nodes are running 0.21.0
Which has what to do with this thread? ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
|
|
|
|
Charles-Tim
Legendary
Offline
Activity: 1638
Merit: 5077
Leading Crypto Sports Betting & Casino Platform
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 18, 2021, 02:58:06 PM Merited by JayJuanGee (1) |
|
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
|
..Stake.com.. | | | ▄████████████████████████████████████▄ ██ ▄▄▄▄▄▄▄▄▄▄ ▄▄▄▄▄▄▄▄▄▄ ██ ▄████▄ ██ ▀▀▀▀▀▀▀▀▀▀ ██████████ ▀▀▀▀▀▀▀▀▀▀ ██ ██████ ██ ██████████ ██ ██ ██████████ ██ ▀██▀ ██ ██ ██ ██████ ██ ██ ██ ██ ██ ██ ██████ ██ █████ ███ ██████ ██ ████▄ ██ ██ █████ ███ ████ ████ █████ ███ ████████ ██ ████ ████ ██████████ ████ ████ ████▀ ██ ██████████ ▄▄▄▄▄▄▄▄▄▄ ██████████ ██ ██ ▀▀▀▀▀▀▀▀▀▀ ██ ▀█████████▀ ▄████████████▄ ▀█████████▀ ▄▄▄▄▄▄▄▄▄▄▄▄███ ██ ██ ███▄▄▄▄▄▄▄▄▄▄▄▄ ██████████████████████████████████████████ | | | | | | ▄▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▄ █ ▄▀▄ █▀▀█▀▄▄ █ █▀█ █ ▐ ▐▌ █ ▄██▄ █ ▌ █ █ ▄██████▄ █ ▌ ▐▌ █ ██████████ █ ▐ █ █ ▐██████████▌ █ ▐ ▐▌ █ ▀▀██████▀▀ █ ▌ █ █ ▄▄▄██▄▄▄ █ ▌▐▌ █ █▐ █ █ █▐▐▌ █ █▐█ ▀▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▀█ | | | | | | ▄▄█████████▄▄ ▄██▀▀▀▀█████▀▀▀▀██▄ ▄█▀ ▐█▌ ▀█▄ ██ ▐█▌ ██ ████▄ ▄█████▄ ▄████ ████████▄███████████▄████████ ███▀ █████████████ ▀███ ██ ███████████ ██ ▀█▄ █████████ ▄█▀ ▀█▄ ▄██▀▀▀▀▀▀▀██▄ ▄▄▄█▀ ▀███████ ███████▀ ▀█████▄ ▄█████▀ ▀▀▀███▄▄▄███▀▀▀ | | | ..PLAY NOW.. |
|
|
|
xmready
Copper Member
Jr. Member
Offline
Activity: 37
Merit: 14
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 18, 2021, 06:44:59 PM |
|
Excited to see how many nodes are running 0.21.0
Which has what to do with this thread? ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) Doesn't 0.21.0 contain the code for Taproot?
|
|
|
|
Charles-Tim
Legendary
Offline
Activity: 1638
Merit: 5077
Leading Crypto Sports Betting & Casino Platform
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 18, 2021, 08:00:17 PM |
|
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.
|
..Stake.com.. | | | ▄████████████████████████████████████▄ ██ ▄▄▄▄▄▄▄▄▄▄ ▄▄▄▄▄▄▄▄▄▄ ██ ▄████▄ ██ ▀▀▀▀▀▀▀▀▀▀ ██████████ ▀▀▀▀▀▀▀▀▀▀ ██ ██████ ██ ██████████ ██ ██ ██████████ ██ ▀██▀ ██ ██ ██ ██████ ██ ██ ██ ██ ██ ██ ██████ ██ █████ ███ ██████ ██ ████▄ ██ ██ █████ ███ ████ ████ █████ ███ ████████ ██ ████ ████ ██████████ ████ ████ ████▀ ██ ██████████ ▄▄▄▄▄▄▄▄▄▄ ██████████ ██ ██ ▀▀▀▀▀▀▀▀▀▀ ██ ▀█████████▀ ▄████████████▄ ▀█████████▀ ▄▄▄▄▄▄▄▄▄▄▄▄███ ██ ██ ███▄▄▄▄▄▄▄▄▄▄▄▄ ██████████████████████████████████████████ | | | | | | ▄▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▄ █ ▄▀▄ █▀▀█▀▄▄ █ █▀█ █ ▐ ▐▌ █ ▄██▄ █ ▌ █ █ ▄██████▄ █ ▌ ▐▌ █ ██████████ █ ▐ █ █ ▐██████████▌ █ ▐ ▐▌ █ ▀▀██████▀▀ █ ▌ █ █ ▄▄▄██▄▄▄ █ ▌▐▌ █ █▐ █ █ █▐▐▌ █ █▐█ ▀▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▀█ | | | | | | ▄▄█████████▄▄ ▄██▀▀▀▀█████▀▀▀▀██▄ ▄█▀ ▐█▌ ▀█▄ ██ ▐█▌ ██ ████▄ ▄█████▄ ▄████ ████████▄███████████▄████████ ███▀ █████████████ ▀███ ██ ███████████ ██ ▀█▄ █████████ ▄█▀ ▀█▄ ▄██▀▀▀▀▀▀▀██▄ ▄▄▄█▀ ▀███████ ███████▀ ▀█████▄ ▄█████▀ ▀▀▀███▄▄▄███▀▀▀ | | | ..PLAY NOW.. |
|
|
|
gmaxwell (OP)
Moderator
Legendary
Offline
Activity: 4228
Merit: 8644
|
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
Copper Member
Jr. Member
Offline
Activity: 37
Merit: 14
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 19, 2021, 05:54:23 PM |
|
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
Legendary
Offline
Activity: 3430
Merit: 3080
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 21, 2021, 05:42:22 PM |
|
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.
|
Vires in numeris
|
|
|
xmready
Copper Member
Jr. Member
Offline
Activity: 37
Merit: 14
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 22, 2021, 01:51:18 AM |
|
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
Legendary
Offline
Activity: 1694
Merit: 7173
In memory of o_e_l_e_o
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 23, 2021, 06:05:02 AM Merited by JayJuanGee (1) |
|
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 (OP)
Moderator
Legendary
Offline
Activity: 4228
Merit: 8644
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 24, 2021, 01:39:35 AM |
|
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
Legendary
Offline
Activity: 3430
Merit: 3080
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 01, 2021, 09:41:34 AM Merited by fillippone (1) |
|
|
Vires in numeris
|
|
|
|