Topic: Taproot proposal - page 9. (Read 11665 times)

I forget the detail of backward compatibility, so i'll just ask it. Why pre-taproot won't relay taproot-transaction? Is it because the transaction missing witness and the (empty ?) script automatically treated as valid script?

The purpose of the delayed activation is to give plenty of time for everyone to upgrade.

Bitcoin doesn't follow the longest chain, it follows the longest valid chain-- and at least to upgraded parties any taproot-invalid chain wouldn't be valid.  So the idea is that it doesn't even matter too much if such an invalid chain is created, as it'll just get ignored and the effect would just be some hashrate vanishing (until the losses cause them to wake up and fix their stuff ).  And this holds no matter how much hashrate there is...

Of course, parties who aren't transacting and are asleep at the switch might not have upgraded but if they're not accepting transactions in realtime it doesn't much matter what chain they are on.

So I think that really takes the wind out of the chaos conspiracy theory.   But it's a good reason to get major exchanges and other influential parties that accept a lot of payments to confirm that they've upgraded prior to activation.

Also, "someone published" isn't sufficient.  Pre-taproot nodes (and miners) will not relay or mine taproot spends.  So the only way a block could be created with an invalid spend in it is if some miner intentionally did so (or at least lobotomized the protection out of their node), even if their software wasn't upgraded.

And technically even after it has locked in we have to wait till November before the 1st tx's and so the 1st Blocks with it in.

Up to that point if a majority of the miners downgraded (or never actually upgraded - just signalled) it would not manage to actually maintain the longest chain so if someone published a currently valid tx that was invalid under taproot we would have a chain split... (I think I am right on this?)

So if you enjoy a good conspiracy theory can run with that scenario... which really would be chaos... BitcoinCash/SV all over again but with Core having the lower hash rate - and nobody maintaining longest chains codebase!

You seem to be misinterpreting.

.

No one is saying it has locked in already.  They're saying we're on course to achieve lock in next period.

It would be important for the bitcoin community (whatever this means) to see universal supporto of a non controversial upgrade, while other subjects propose controversial agreements on different topics.

Yes, but as I checked it recently, the percentage is now over 96%



I noticed Rawpool are signalling already, also most likely that BTC.com are fully signalling.

Looks like we are there! 

BTC.com has signalled with all of their last 7 blocks!

So assuming no miner changes their mind will lockin around the Sat 12th June.

Nice addition to taproot.watch

They now added a "Stats" tab where you can look at the graph of Taproot activation percentage:



We see percentage hovering around 90%.
This bode well for next period, with all. the known caveats about how this website computes the harshpower!

yay 💪👌


https://www.reddit.com/r/Bitcoin/comments/nj1z6o/yesterday_was_the_first_full_day_with_over_90/

in addition, taproot.watch has now created a stats, in which you can better represent the signalling
https://taproot.watch/stats

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.

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.

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

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

yeeeeesss... o_O

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

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.

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!

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

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

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