Taproot proposal

[kano]

majority of network does not just stop mining their own block attempt when first seeing a new block header.
majority of network actually continues its block effort until a new block is validated.

...
anyway. as for your "not sure where you got that statement from but its not true"
i quoted YOU. infact you quoted me quoting you. thus double obvious where that statement came from
...
seems your forgetting what you wrote and then spinning a different version of events as if you never said the first version of events you implied even when its clearly been quoted of what you said

I've said the exact opposite of what you said:
majority of the network does stop mining their own block attempt when first seeing a new block header. <- they immediately build on a new unverified header
majority of network actually doesn't continues its block effort until a new block is validated. <- it doesn't continue mining the old block, it builds a new empty block on top of the unverified header

i.e. the majority of the network switches to the next block when it sees the block header, before validating the merkleroot/transactions,
i.e. the majority of the network mines on an unverified block every block change for a short period of time

one last time.. so take a seat. relax and slowly understand things. have a cup of coffee after and actually let the information be absorbed.
YOU said majority of network would build onto a invalid block..
I SAID no. majority of blocks are NOT built ontop of via the 'empty block strategy'
as proven by only 280 blocks out of 58000 blocks statistic

This has nothing to do with it.
The issues is e.g. if anyone creates a block with a taproot transaction before it's valid, the majority of the network will accept it at the point of the block change, because they don't verify transactions before they send their miners a new empty block to mine.

You said 0.5% is the % of empty blocks.
That shows how long, on average, it takes to switch from an empty unverified header to a verified header with transactions.
i.e. 0.5% of the average 10minute block - or 3 seconds.

Really I'm not sure why I'm repeating myself, go read:
https://bitcointalk.org/index.php?topic=5251592.0

[franky1]

i know you are saying that the majority do empty block
but that is YOUR opinion and YOUR pre-set mindset.
its not what the reality of what the network is doing

a empty block occurs 0.5% of the time. of blocks (seems you think i meant time as in time)
however when there is a stale block. its because pools are continuing to mine their attempt while validating a block

if the network was majority empty block mining before validating previous blocks the network would see more stales and orphans than it actually does

the empty block/stales and orphan occurrence is super low. indicating the use of a 'pre-validation empty block' strategy is not the norm/majority.

..
yes there is a valid concern IF pools were all idiots and were spv mining and empty block mining. . but they are not.
put it another way
starting a new block many seconds before a pool that full validates a broadcast block would give the empty block pool a headstart. meaning if majority of pools were doing it the majority of blocks would solve their empty block faster than a full validation pool
this would end up with majority of blocks being empty blocks. but reality of 2020 show 0.5%

so i hope you can understand 0.5% of the network do empty blocks because 0.5% of blocks in 2020 were empty blocks

so calm down your fears. as its not a 'majority of network' thing
once and for all realise YOUR opinion of how many pools are empty mining without validation is YOUR error of judgement and causing you to endlessly spiral down a argument of meaningless fear

so move on. the network is safe

EDIT: below kano wants to continue a derail about his beleifs that the network is weak because in his mind every pools uses crappy stratum software that doesnt validate blocks..
he pretends empty blocks are all found in 3 seconds

yet looking at block data just today
if all pools were empty blocking and all empty blocks were found in 3 seconds. then all blocks would be 3 seconds apart and empty

however i found one of the rare empty blocks.. and strangely it was 3 MINUTES after its previous block
687238-687239

seems kano has been reading too many 'bitcoin is broken' conspiracy tweets where they always finger point at the pools(facepalm)

..
anyway back on topic.
TR locked in. no drama no fuss.
i personally wont be using it as i prefer my keys spread out and unaffiliated. but glad there was no coercion/mandates to get this upgrade going

[fillippone]

In the meantime, just for the record, taproot has been locked in at block height  687284.
A little bit loud celebration movie on taproot.watch

https://content.taproot.watch/taproot.mp4

A big step in the protocol.

[kano]

...
Edit: if you wish to test this, mine on a large pool that produces empty blocks and look at the 1st work sent each block change.

Repeat: 0.5% of blocks being empty means they are mining empty work 0.5% of the time that they are mining.

If you mine empty work 100% of the time you mine, then all your blocks will be empty.
If you mine empty work 50% of the time you mine, then 50% of your blocks will be empty.
If you mine empty work 0.5% of the time you mine, then 0.5% of your blocks will be empty.

So why 0.5%?
Because that's the average time (3 seconds) they spend mining empty work on a block change, before they switch to mining non-empty work.

It's not a guess, it's a simple fact.

So why do they mine empty work for 0.5% of the time?

Well I've answered that above as well.

[j2002ba2]

please take some time to look at some block data.

take block 687238 (full block)
take block 687239 (empty block)
hmm 3 minutes apart
yep i said minutes. blockchain said minutes. network says minutes

empty blocks are not found in 3 seconds.. sorry

This proves nothing, since block timestamp is only loosely tied to the real time, and can be within 7200 seconds (IIRC) of what you think. The difference can be negative as well.

Look at the block timestamps:
687238: 2021-06-12 03:29:54
687239: 2021-06-12 03:32:22
687240: 2021-06-12 03:30:56

If you had a full node running at that time, please look at debug.log for the timestamps of UpdateTip - this is when you received the block, and should be closer to the real time of mining it.

[AdolfinWolf]

Any information on when bitcoin core will release support for schnorr signatures? Interested in playing around with it on testnet, but there don't seem to be any real implementations available/enabled yet? (Not regtest!)

[gmaxwell]

If you had a full node running at that time, please look at debug.log for the timestamps of UpdateTip - this is when you received the block, and should be closer to the real time of mining it.

If you have the bench debug group enabled it's really easy to grep for blocks with just 1 transaction.

grep 'transactions:' debug.log | cut -d':' -f1-3 | grep -B 1 ' 1 trans'

What you find is that they all came very close to the prior block:


2021-05-05T19:38:25.972767Z       - Connect 2809 transactions
2021-05-05T19:38:34.570897Z       - Connect 1 transactions
--
2021-05-06T01:41:17.380671Z       - Connect 1819 transactions
2021-05-06T01:41:18.663782Z       - Connect 1 transactions
--
2021-05-07T07:51:09.129202Z       - Connect 1012 transactions
2021-05-07T07:51:14.330562Z       - Connect 1 transactions
--
2021-05-07T19:48:50.111346Z       - Connect 2083 transactions
2021-05-07T19:48:53.097904Z       - Connect 1 transactions
--
2021-05-07T22:45:39.073813Z       - Connect 1590 transactions
2021-05-07T22:45:47.849924Z       - Connect 1 transactions
--
2021-05-09T11:03:47.903862Z       - Connect 137 transactions
2021-05-09T11:03:49.012120Z       - Connect 1 transactions
--
2021-05-09T15:08:38.912208Z       - Connect 836 transactions
2021-05-09T15:08:50.059076Z       - Connect 1 transactions
--
2021-05-09T15:29:45.090009Z       - Connect 1022 transactions
2021-05-09T15:29:51.787654Z       - Connect 1 transactions
--
2021-05-11T04:24:42.477370Z       - Connect 1265 transactions
2021-05-11T04:24:43.989771Z       - Connect 1 transactions
--
2021-05-11T06:45:07.349646Z       - Connect 1894 transactions
2021-05-11T06:45:08.451109Z       - Connect 1 transactions
--
2021-05-12T12:54:19.522383Z       - Connect 2698 transactions
2021-05-12T12:54:23.530026Z       - Connect 1 transactions
--
2021-05-13T05:45:32.793978Z       - Connect 1378 transactions
2021-05-13T05:45:33.117047Z       - Connect 1 transactions
--
2021-05-13T22:38:09.974322Z       - Connect 1012 transactions
2021-05-13T22:38:11.649618Z       - Connect 1 transactions
--
2021-05-14T23:23:24.842750Z       - Connect 1964 transactions
2021-05-14T23:23:47.495929Z       - Connect 1 transactions
--
2021-05-18T17:47:19.628403Z       - Connect 3164 transactions
2021-05-18T17:49:39.760471Z       - Connect 1 transactions
--
2021-05-19T17:31:36.584356Z       - Connect 2231 transactions
2021-05-19T17:31:37.058632Z       - Connect 1 transactions
--
2021-05-22T10:36:24.375540Z       - Connect 1708 transactions
2021-05-22T10:36:27.893624Z       - Connect 1 transactions
--
2021-05-22T22:19:00.620185Z       - Connect 1623 transactions
2021-05-22T22:19:16.254926Z       - Connect 1 transactions
--
2021-05-23T07:32:16.229073Z       - Connect 357 transactions
2021-05-23T07:32:19.123820Z       - Connect 1 transactions
--
2021-05-23T09:58:10.283078Z       - Connect 2490 transactions
2021-05-23T09:58:11.571934Z       - Connect 1 transactions
--
2021-05-27T02:07:09.620112Z       - Connect 2145 transactions
2021-05-27T02:07:18.611398Z       - Connect 1 transactions
--
2021-05-28T01:37:24.493782Z       - Connect 2135 transactions
2021-05-28T01:37:26.807828Z       - Connect 1 transactions
--
2021-05-29T15:53:09.574103Z       - Connect 196 transactions
2021-05-29T15:53:20.028246Z       - Connect 1 transactions
--
2021-05-29T22:00:58.635862Z       - Connect 3170 transactions
2021-05-29T22:01:01.087364Z       - Connect 1 transactions
--
2021-05-30T03:13:14.704155Z       - Connect 417 transactions
2021-05-30T03:13:22.371535Z       - Connect 1 transactions
--
2021-06-03T19:14:18.999147Z       - Connect 2527 transactions
2021-06-03T19:14:20.161540Z       - Connect 1 transactions
--
2021-06-04T06:00:27.274780Z       - Connect 2128 transactions
2021-06-04T06:00:49.580074Z       - Connect 1 transactions
--
2021-06-04T09:57:56.541947Z       - Connect 2295 transactions
2021-06-04T09:57:58.988411Z       - Connect 1 transactions
--
2021-06-11T19:11:20.520707Z       - Connect 2294 transactions
2021-06-11T19:11:22.028495Z       - Connect 1 transactions
--
2021-06-12T03:30:34.207538Z       - Connect 2369 transactions
2021-06-12T03:30:36.134363Z       - Connect 1 transactions
--
2021-06-12T08:47:34.116659Z       - Connect 1095 transactions
2021-06-12T08:47:36.855799Z       - Connect 1 transactions



Here are the time differences:


8.59813
1.283111
5.20136
2.986558
8.776111
1.108258
11.146868
6.697645
1.512401
1.101463
4.007643
0.323069
1.675296
22.653179
140.132068
0.474276
3.518084
15.634741
2.894747
1.288856
8.991286
2.314046
10.454143
2.451502
7.66738
1.162393
22.305294
2.446464
1.507788
1.926825
2.73914



    Min.  1st Qu.   Median     Mean  3rd Qu.     Max.
  0.3231   1.5101   2.8948   9.8381   8.6871 140.1321


With a 3rd quartile of 8.68 seconds, the idea that these blocks are coming long after prior ones is clearly false.  There is only one case where I observed one more than 30 seconds later-- and that could be a newly restarted miner, or a case where my timestamp wasn't accurate due to connectivity or propagation issues (or, indeed, a miner that ought to be yelled at: it was block 00000000000000000001eab20e0edf01c17bd8522f132b7c1f88449281fffcdc).

Any information on when bitcoin core will release support for schnorr signatures? Interested in playing around with it on testnet, but there don't seem to be any real implementations available/enabled yet? (Not regtest!)

There is a PR for wallet support: https://github.com/bitcoin/bitcoin/pull/21365

[kano]

...
There is only one case where I observed one more than 30 seconds later-- and that could be a newly restarted miner, or a case where my timestamp wasn't accurate due to connectivity or propagation issues (or, indeed, a miner that ought to be yelled at: it was block 00000000000000000001eab20e0edf01c17bd8522f132b7c1f88449281fffcdc).
...

Alas, I get the same numbers for that one, so either 'one_more_mcd' restarted the bitcoind that sent work to the miner that found it, or 'NFI'
(aside this log was running 0.20.1)

Code:

2021-05-18T17:47:19.602108Z ProcessNewBlock
2021-05-18T17:47:19.602162Z  PNB cb sig='0x03Jp0x0a0x040x920xfd0xa3`/poolin.com/taproot/bip9/0xe10xd90xa50x7f0xc30xdd0xc60xc00xfd0x9e0xdar0xaf0xd10xa0$0x0f0x100xdb0xe70xd90x000xf20xc60x000x000x000x000x000x00' (64)
2021-05-18T17:47:19.665777Z UpdateTip: new best=000000000000000000069f86c3aac46c79cdea2bee3098125ba194442cc3138c height=684106 version=0x20c00004 log2_work=92.886863 tx=643180771 date='2021-05-18T17:46:54Z' progress=1.000000 cache=107.3MiB(785733txo) warning='97 of last 100 blocks have unexpected version'

2021-05-18T17:49:39.674310Z ProcessNewBlock
2021-05-18T17:49:39.674360Z  PNB cb sig='0x03Kp0x0a,0xfa0xbemm6R0x9f0xbd0xb90x050xafd0x94Qv0xf60xb10xe30xce0xe10x0f0xca0x11U0xc8;0x92@4cwx=0xf70x0000x100x000x000x000xf00x9f0x940xa5/one_more_mcd/0x080x010x050xd70x000xbd0x000x010x00' (72)
2021-05-18T17:49:39.677318Z UpdateTip: new best=00000000000000000001eab20e0edf01c17bd8522f132b7c1f88449281fffcdc height=684107 version=0x20600004 log2_work=92.88688 tx=643180772 date='2021-05-18T17:49:12Z' progress=1.000000 cache=107.4MiB(786189txo) warning='97 of last 100 blocks have unexpected version'

[darkv0rt3x]

Random question:

If we already have 98% (or so) of the last blocks signalled with Taproot, why to wait for November or so to make this permanent on the blockchain/system?

[achow101]

Random question:

If we already have 98% (or so) of the last blocks signalled with Taproot, why to wait for November or so to make this permanent on the blockchain/system?

Signaling does not necessarily mean that the everyone running a node, including miners, has upgraded their node(s) to support the new rules. The delay between locking in and activation is to allow for everyone to upgrade. Now that we all know that taproot is going to activate, it's time for everyone who hasn't upgraded yet to upgrade so that they aren't at any risk.

For taproot specifically, the long time delay is part of the Speedy Trial method. The first signaling window began very soon after the software implementing the parameters was released. This was not sufficient time for everyone to upgrade. In general, it is not believed that enough nodes would upgrade during the 3 month window for the signaling periods. So the suggestion was to make activation occur 3 months after the expected final signaling window. This allows for a total of 6 months for everyone to upgrade their nodes before activation occurs. This strategy is in contrast to previous deployments where the software was released several months before signaling could begin thereby allowing nodes to upgrade prior to signaling.

[darkv0rt3x]

Random question:

If we already have 98% (or so) of the last blocks signalled with Taproot, why to wait for November or so to make this permanent on the blockchain/system?

Signaling does not necessarily mean that the everyone running a node, including miners, has upgraded their node(s) to support the new rules. The delay between locking in and activation is to allow for everyone to upgrade. Now that we all know that taproot is going to activate, it's time for everyone who hasn't upgraded yet to upgrade so that they aren't at any risk.

For taproot specifically, the long time delay is part of the Speedy Trial method. The first signaling window began very soon after the software implementing the parameters was released. This was not sufficient time for everyone to upgrade. In general, it is not believed that enough nodes would upgrade during the 3 month window for the signaling periods. So the suggestion was to make activation occur 3 months after the expected final signaling window. This allows for a total of 6 months for everyone to upgrade their nodes before activation occurs. This strategy is in contrast to previous deployments where the software was released several months before signaling could begin thereby allowing nodes to upgrade prior to signaling.

Ok, makes sense, now that things are more thoroughly explained! I know that there was some fuss about how to get the consensus of the community and about how miners seems to have a more relevant position when it comes to decide what to accept and what to reject and I think this should be a global (but within the community) decision.

Anyway, I think this is all good for bitcoin for most of the reasons and I hope the people that wishes good for bitcoin, all welcome these changes!

[fillippone]

As I am a casual, not technical observer, I was quite surprised by this thread by @sipa. As at least one person in this thread is involved, I am asking some colour about this:


https://twitter.com/pwuille/status/1403725170993336322?s=21

He goes on with his own recap of the story: who would have guessed about the idea of all this being drawn on the proverbial napkin?



A good read.

[kano]

Random question:

If we already have 98% (or so) of the last blocks signalled with Taproot, why to wait for November or so to make this permanent on the blockchain/system?

Signaling does not necessarily mean that the everyone running a node, including miners, has upgraded their node(s) to support the new rules.
...

In fact if this site is accurate:

https://bitnodes.io/nodes/

Only 46% of nodes are at 0.21+ as at the moment, even though miners have already locked it in.
Seems the non-mining community is dragging it's feet.

[pooya87]

In fact if this site is accurate:

https://bitnodes.io/nodes/

Only 46% of nodes are at 0.21+ as at the moment, even though miners have already locked it in.
Seems the non-mining community is dragging it's feet.

It is not accurate because it contains a lot of "fake nodes" that are usually placed on top of the list and are only there to "spy".
As for the version I believe that it should only be 0.21.1 since it has the Taproot activation code not 0.21.0 which makes the percentage 24.23%. It also doesn't have Bech32m which may not be as important since Taproot won't be activated for months but without it your client won't be able to recognize witness version 1 addresses.

[gmaxwell]

My spy filtered node counts 36% of its peers as taproot supporting right now, FWIW.

(earlier I was confused that this was _lower_ than the above figure-- I expected it be higher, but I missed that kano had apparently overcounted by including 0.21.0 and now all is clear! )

[kano]

My spy filtered node counts 36% of its peers as taproot supporting right now, FWIW.

(earlier I was confused that this was _lower_ than the above figure-- I expected it be higher, but I missed that kano had apparently overcounted by including 0.21.0 and now all is clear! )

Ah OK, yes I was including 0.21.0 - I completely skipped going anywhere near that version, but thought it included the necessary code.
My bad.

I tend to be slow updating my pool ... to let others find the problems
While I was probably one of the last few pools to update, since the deadline was November I left it until just before the lock in.

[cygan]

Taproot is a win for everyday users...
Taproot is a win for sophisticated users too...
Taproot is a win for the Lightning Network...
Taproot is a win for the community overall...
Taproot is undoubtedly a significant improvement...

https://bitcoinmagazine.com/culture/taproot-bitcoin-win-logic

[kano]

Meanwhile, some noob pool shows up and mines a block without the taproot flag ... lulz.

Block 689182

[pooya87]

Meanwhile, some noob pool shows up and mines a block without the taproot flag ... lulz.

Block 689182

But Taproot is already locked in and can not be changed, there is no point in signalling for it anymore since full nodes stopped counting.

[gmaxwell]

But Taproot is already locked in and can not be changed, there is no point in signalling for it anymore since full nodes stopped counting.

Well not no point, it provides at least some indication that they probably haven't accidentally downgraded their configuration.

(but not much, since essentially all signaling is not driven by the node itself)