Taproot proposal

[cygan]

Taproot now has more than the required minimum of miners signaling support to lock in the upgrade, but the upgrade isn’t a shoe-in just yet.

Per the activation rules set by Speedy Trial, 90% of blocks mined within one of Bitcoin’s difficulty periods need to signal support for the upgrade for it to be locked in for activation in November.

https://www.coindesk.com/when-will-bitcoin-taproot-upgrade-lock-in

[fillippone]

Taproot now has more than the required minimum of miners signaling support to lock in the upgrade, but the upgrade isn’t a shoe-in just yet.

Per the activation rules set by Speedy Trial, 90% of blocks mined within one of Bitcoin’s difficulty periods need to signal support for the upgrade for it to be locked in for activation in November.

https://www.coindesk.com/when-will-bitcoin-taproot-upgrade-lock-in

Indeed.
It's nice seeing the "community", in a broad sense, cooperate on a hugely non-controversial update, even more on a difficult time for bitcoin, that is under attack on many fronts.But signaling for activation in the third or fourth or any other period of the speedy trial won't change the timeline.

[achow101]

I think we are there!

All 11 of the top 11 pools are signalling with all blocks. As are 3 other smaller pools.
So voting over 94%.

Assuming no pool changes its mind, and there is no shift in miners to non-signalling pools then lock-in around the 11/12th June is certain to happen.

btc.com is still not fully signaling. My monitoring of them indicates that they are only issuing work that signals for Taproot on 1 out of 4 of their stratum servers. This is consistent with the number of signaling blocks that they have been mining too, as most of their blocks do not signal.

[Charles-Tim]

btc.com is still not fully signaling. My monitoring of them indicates that they are only issuing work that signals for Taproot on 1 out of 4 of their stratum servers. This is consistent with the number of signaling blocks that they have been mining too, as most of their blocks do not signal.

I agree with that. From Block 684317 that was mined 10 hours ago to the recent block mined when I posted this, Block 684368. It would be noticed that BTC.com is not fully signalling. Also if Rawpool can signal and fully signal, it will almost make all new blocks mined to be part of blocks that signal for taproot activation.

Block that did not signal right from block 684317that was mined ten hours ago to block 684368 that was mined few minutes ago before I posted this.
Block 684317: BTC.com
Block 684327: Rawpool
Block 684329: Unknown mining pool
Block 684330: Arkpool
Block 684332: BTC.com
Block 684333: Rawpool
Block 684350: Rawpool
Block 684367: BTC.com

[Wind_FURY]

BTC.TOP signalling too - so now all of the top 12 pools have signalled one or more blocks - so if they all signal full time up at about 95%.

we can slowly put the hats on


https://twitter.com/BitcoinMemeHub/status/1394473764365217795

Everyone can slowly wear their masks on too, https://taproot.fish/

What is wrong with BTC.com? They signalled for Taproot, then they stop signalling? Is this just a simple problem with not fully upgrading all their servers/nodes, or something else? There are 85% of miners signalling, BTC.com holds 10% rounded off.

https://taproot.watch/miners

[pooya87]

Is this just a simple problem with not fully upgrading all their servers/nodes, or something else? T

Most probably yes.
Some mining pools seem to be slow at rolling out the upgrade to all their servers and end up only updating one at a time which is why the numbers are lower than 100%.
It seems like we could get locked_in after the next difficulty adjustment though.

[Karartma1]

Is this just a simple problem with not fully upgrading all their servers/nodes, or something else? T

Most probably yes.
Some mining pools seem to be slow at rolling out the upgrade to all their servers and end up only updating one at a time which is why the numbers are lower than 100%.
It seems like we could get locked_in after the next difficulty adjustment though.

Not every pool is like SlushPool However, it could well be that if it's not the actual next period maybe it could be the next one.
From the data available, it doesn't look like miners will not follow and I'm pretty confident we'll have it updated soon. I want to see it in action, as theory-wise is still so foggy to me.

[Carlton Banks]

Taproot won’t be activated in this period.

As I write we are above 78.08%: only 12% missing. Not so bad  

hmm, checking the stats on my node (using bitcoin-cli getblockchaininfo), only 72.5% of blocks have signalled this difficulty period. Maybe I'm reading it wrong?

whatever the true stats are, the number is clearly climbing.

[fillippone]

Taproot won’t be activated in this period.

As I write we are above 78.08%: only 12% missing. Not so bad 

hmm, checking the stats on my node (using bitcoin-cli getblockchaininfo), only 72.5% of blocks have signalled this difficulty period. Maybe I'm reading it wrong?

whatever the true stats are, the number is clearly climbing.

I guess, I could check the computation, but I am lazy, that the website considers a pool signalling for readiness when the last block found is signalling readiness.
When the pool is considered signalling, then 100% of the hash rate of such pool is added to the sum.
So it is quite misleading when a pool signals only a few blocks (because not everyone amongst their miners is actually signalling) as the actual ratio is lower, as your node signals.

But this is too simple for you, maybe I didn’t even understand what you said!

[ABCbits]

Taproot won’t be activated in this period.

As I write we are above 78.08%: only 12% missing. Not so bad  

hmm, checking the stats on my node (using bitcoin-cli getblockchaininfo), only 72.5% of blocks have signalled this difficulty period. Maybe I'm reading it wrong?

whatever the true stats are, the number is clearly climbing.

I think you read the statistic incorrectly, if you think "count": 725, means 72.5% block signal Taproot, then it's incorrect. According to "help getblockchaininfo", it refers to number of block which signal taproot. CMIIW.

Code:

"taproot": {
      "type": "bip9",
      "bip9": {
        "status": "started",
        "bit": 2,
        "start_time": 1619222400,
        "timeout": 1628640000,
        "since": 681408,
        "statistics": {
          "period": 2016,
          "threshold": 1815,
          "elapsed": 987,
          "count": 725,
          "possible": false
        },
        "min_activation_height": 709632
      },
      "active": false
    }
  },

Code:

 "count" : n,                    (numeric) the number of blocks with the version bit set in the current period

[Carlton Banks]

I think you read the statistic incorrectly, if you think "count": 725, means 72.5% block signal Taproot, then it's incorrect. According to "help getblockchaininfo", it refers to number of block which signal taproot. CMIIW.

Code:

"taproot": {
      "type": "bip9",
      "bip9": {
        "status": "started",
        "bit": 2,
        "start_time": 1619222400,
        "timeout": 1628640000,
        "since": 681408,
        "statistics": {
          "period": 2016,
          "threshold": 1815,
          "elapsed": 987,
          "count": 725,
          "possible": false
        },
        "min_activation_height": 709632
      },
      "active": false
    }
  },

Code:

 "count" : n,                    (numeric) the number of blocks with the version bit set in the current period

no, I'm doing 725 / 987 = 0.7345 (see, I told you it was climbing )

my interpretation is that "count" signifies "blocks signalling taproot BIP9, in this 2016 block difficulty period" and that "elasped" signifies "total blocks mined out of this 2016 block difficulty period"

I think the difficulty period and the signalling period are synonymous, I'm just trying to simplify the details (plus I'm not sure either )

[Charles-Tim]

I think you read the statistic incorrectly, if you think "count": 725, means 72.5% block signal Taproot, then it's incorrect. According to "help getblockchaininfo", it refers to number of block which signal taproot. CMIIW.

Code:

"taproot": {
      "type": "bip9",
      "bip9": {
        "status": "started",
        "bit": 2,
        "start_time": 1619222400,
        "timeout": 1628640000,
        "since": 681408,
        "statistics": {
          "period": 2016,
          "threshold": 1815,
          "elapsed": 987,
          "count": 725,
          "possible": false
        },
        "min_activation_height": 709632
      },
      "active": false
    }
  },

Code:

 "count" : n,                    (numeric) the number of blocks with the version bit set in the current period

no, I'm doing 725 / 987 = 0.7345 (see, I told you it was climbing )

my interpretation is that "count" signifies "blocks signalling taproot BIP9, in this 2016 block difficulty period" and that "elasped" signifies "total blocks mined out of this 2016 block difficulty period"

I think the difficulty period and the signalling period are synonymous, I'm just trying to simplify the details (plus I'm not sure either )

I am not running Bitcoin core or any full node, but with what I calculated from https://taproot.watch/, Carlton Banks is right as it is the same as my calculation here while used 726 signalling blocks and 262 non-signalling blocks.

From the site, I got this data

• 726 signalling blocks
• 1028 upcoming blocks
• 262 non-signalling blocks

But to know the present total percentage of the blocks that signalled, I excluded the upcoming blocks, so I used only signalling and non-signalling blocks for it.

Signalling blocks + non-signalling blocks = recent total blocks mined (2016 height)

726 + 262 = 988

Percentage of signalling blocks = signalling blocks divided by total recent block mined (within 2016 block height) multiply by 100

Percentage of signalling blocks = 726 ÷ 988 * 100 = 73.48

Percentage of recent signalling blocks = 73.48

[j2002ba2]

Percentage of recently (last 144) signaling blocks is 86.8% = 125/144

https://taproot.watch shows the percentage of current period (73.5% right now) above red/green blocks at the right, but for some reason only before it's clear that current period couldn't lock-in (before 202 non-signaling blocks).

[nibor]

I think the percentage on the taproot.watch site is calculated by looking at the percentage of blocks each pool has produced in this period (its % hash rate).

It then sums the % hash rate (over the current period) of all the pools that signalled on their LAST block.

So is effectively forward looking.

But annoyingly BTC.COM has only partly upgraded their infrastructure. So only about 1/3 of their blocks are signalling. They count for about 10% hash rate.

If their last block was a signalling block their 10% is included (so jumps to 94%) if their last block was not signalling they are not included so rate drops to 84%.

I think BTC.com said on twitter they should be signalling full time by end of this week. Assuming they do then is a dead cert for next period - otherwise will be very tight!

[Carlton Banks]

Assuming they do then is a dead cert for next period - otherwise will be very tight!

hashrate can be added or removed at any time. So maybe. But it looks pretty positive.



1006 blocks out of 2016, 741 of which signaled. Looking decent. 74% at near the half-way mark, maybe that will improve.

[nibor]

hashrate can be added or removed at any time. So maybe. But it looks pretty positive.

Price could drop to $1 and all the miners switch to Bitcoin Cash too and us never get to another reset period.. lots of things can still go wrong you are correct

[Carlton Banks]

Price could drop to $1 and all the miners switch to Bitcoin Cash too and us never get to another reset period.. lots of things can still go wrong you are correct

yeeeeesss... o_O

it's slightly more likely that more hashrate will be added/removed than those things though. slightly

[cygan]

...

1006 blocks out of 2016, 741 of which signaled. Looking decent. 74% at near the half-way mark, maybe that will improve.

https://twitter.com/BitcoinMemeHub/status/1388882687755227150

i think that the whole signaling procedure will find a positive and relatively quick end after all 

[fillippone]

I don't know if the guys at Taproot.watch read this thread, but today they modified their website like the following:



So now they consider the %age of the hash rate currently signalling. Again, they look only at the last block, and the hashrate is considered all signalling, even if the actual percentage of "green" blocks amongst the ones mined by the pool is reduced. 
The potential hash rate is the sum of all the miners who have signalled at least one block.

Again, pretty creative, but in the end, the result doesn't change much: we are getting there.

[gmaxwell]

It's normal for pools to have multiple servers.  Some have upgraded partially for risk reduction reasons, presumably they'll go ahead and upgrade the rest when they're confident that the upgrade is stable.

Taproot.watch now has a "Potential" field, which counts all partially signaling pools as fully signaling pools all the time (instead of only when their latest block signaled).  It currently reads 95.61% --- meaning if BTC.com & others who are partially upgraded fully upgrade before the next window it is extremely likely that it will lock in during that window.