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

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?

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)

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


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

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

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.

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.

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.

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

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

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://bitcointalksearch.org/topic/why-not-to-mine-on-pools-mining-empty-blocks-and-why-do-pools-mine-empty-blocks-5251592

oh kano...(facepalm)
no the 0.5% is not some time conversion meaning 3 seconds(your premiss)
its actually the blocks that occured throughout 2020 where out of 58000 blocks only 280 of them were empty blocks. its got nothing to do with YOUR "3 second" maths of 600seconds / 5%.

its got everything to do with the small insignificant utility of doing empty blocks

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

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

i debunked you by showing you the under 280 of 58000 stat for 2020. which shows that majority of pools DO NOT build ontop of invalid blocks due to the low amount of empty block strategy being used.

i hope you get it now. accept that empty block strategy is not used as often as you presume

.
now a reminder of the math. for the last time. so please allow it to soak in
0.5% is the number of empty blockers (those who build on a block thats not been validated yet)
5% is the under 5% that have not signalled a desire to upgrade to TR
=under 0.025% that 'could' ignorantly accept an errored block
then with other factors included..(basically assuming a 10% risk/intent) puts it at a 0.0025% risk of an intentional event.

...
so lets just pretend you stepped a few steps forward and realised the chance of it happening is 0.0025%

your then asking what about those that then build on top of that
seriously your talking about "those".. meaning you want to interrogate who the 0.0025% pools are
well it does not matter in the end. as its a small insignificant proportional risk of a insignificant amount that would want to make an alt. and even if they did. so be it. they are an alt.. bye bye moving on

meaning 99.975% have rejected that block and moved on and just accepting normal blocks
yawn. no drama. non event. didnt even notice it happen coz its such an insignificant event
just like all other orphans that have ever occured in the last 12 years that no one talks about or realised even occured unless they specifically went and looked

realise that is like a negligible amount/opportunity that would make their own altcoin if they wished to proceed down their path. and thus it does not impact the rest of the network
..
the orphan rate drama just self regulates it out.
at a risk of 0.0025%
a meaningless number of insignificance

again.. the chances of a pool making an empty block is about 280 out of say 52k+
the chances of a empty block building ontop of a faulty block due to not being an upgraded node is even less
the chance of a pool  normal game theory incentive. and intentionally wanting to cause an error even less

so please stop saying/thinking that majority of the network does the empty block strategy, let alone other false presumptions
because stats show the very opposite.

majority of stratum servers(pools) are NOT SPV nodes making empty blocks

this is the final time im going to repeat myself. because it seems you are not understanding stats and numbers and quotes
step passed your pre conceived notion that majority of pools are amateurs that use crappy stratum software.
as thats not reality.

No idea who you got that statement from, but it's not true.

Yep, that's the time spent mining on non-validated blocks.
average 600 seconds per block, 0.5% gives an average of 3 seconds per block change.

Not a very small number ... though using your numbers 0.5% times 5% is ... 0.025%
As I've made clear before, the issue is what the other pools do on top of the following valid block if it is quick.

Statistics says it doesn't matter how long it took to find the first block, since it's already been found, the next block is the same probability or 0.5% chance of finding a quick block on the empty block and continuing the bad chain.

In the past when this happened, two big pools went off on their own invalid chain, with a hash rate close to half the network, and continued that until FUPool noticed the issue in their discussion channel and I contacted Bitmain.

It has nothing to do with wallets, it's to do with SPV mining - though that term has been modified after it's inception to include something else.

I guess the more recent name is 'Spy-mining' where a pool gets the work change from a miner connected to other pools, and uses the header in the miner to switch to the next block.
Since they don't know what transactions were used to produce the block, they must mine an empty block until they get and verify the full block.
Same can be done with a hacked bitcoind itself and use the header when it's first received before validating the block, and again the same reason: they don't know what transactions where used yet, so must mine an empty block until they verify it.

However, it's simply a case of ignorance, resistance to change and following what the other big pools do.

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.

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.

less than 0.5% of blocks are 'empty blocked' (280blocks of 58k are empty(2020stats))
adding to that the amount of pools that are not signalling for TR is under 5%

so at very max its a 0.5% of 5%. meaning with other factors at play. the end the result is a 0.0025% risk
definitely not a 'majority of network will mine'

so calm down(seems im repeating myself)
um i dont think any would. as the odds are super low
as there is no large economic incentive /positive reason to waste so much cost on doing this intentionally. (standard game theory)
but it seems you believe majority of pools will do this because its your belief that majority of pools do use crappy stratums and spv wallets and do empty blocks as standard.. so maybe you should be asking yourself which pools would be doing this.

Alas this is the majority of the Bitcoin hashrate.

While it is only a short timeframe after each block change, the majority of the network hashrate will mine on an invalid transaction for a short period of time after the block change.

As I've mentioned before, the issue is if anyone else then finds a quick block without any invalid transactions in it, on top of the invalid one, what pools will continue on that block, and for how long?

as long as this activation does not include code/rule to only accept a new flag number/version number block then no hardfork/no mandatory split will occur.. thankfully
so far no plans to do so.. thankfully this time

as usual and has always been the case
blocks that dont meet the rules of validation get rejected as standard.
as gmax said

meaning and as already said in previous posts.
(unupgraded nodes blindly accept new tx formats)

the only fork risk is if non-upgraded nodes blindly accepts a duff(bad/error/invalid) block which a upgraded node rejects as part of normal consensus.
 
and the unupgraded node is continually getting new blocks that build ontop of the duff block.
but this is like a below 0.0025% chance of occuring. and only affects that small percentage of users in that case. so not a 5% or 50% risk. but a 0.0025% risk. and only to those in that small group

meaning an igornant/intentional pool and a few nodes solely peered to it, will have to intentionally build ontop a duff block for them to make their own altcoin

No blocks will be rejected unless they contain an invalid taproot spend after the lock-in height or are a descendant block of a block that has an invalid spend.  By invalid I mean breaks the taproot rules, e.g. last a signature or has one that doesn't pass validation.

The normal construction of softforks tries pretty hard to avoid creating any conflicting chain, as much as is possible.

hmmm, I thought that the October/November activation simply permits witness v1 spends? (and so any non-upgraded miner will reject blocks containing witness v1 spends, and subsequently find themselves mining a fork)

They won't start rejecting blocks immediately even though lockinontimeout=true, because the timeout is all the way at the end of October. That's when non-signaling blocks will start being rejected. It will not be activated at the end of a successful signaling period.

i couldn't figure one thing out here after this period ends assuming that taproot gets locked in are we going to start rejecting those blocks that don't signal for taproot or does it all end and we forget about it until November that it activates then reject them?

Here's an update about Taproot (after a distracted comment about price):

I know.  I know.  I know.  Some people are getting depressed about ongoing testing of buy support and wondering how far the low is going to be able to go ...and many (including yours truly) don't want to say anything.. which is understandable - even if we have positive happenings of getting more and more good news about Taproot getting locked in during this difficulty period, that a day ago, I had already asserted, with a wee tiny bit of trepidation, to be in the ballpark of inevitable ... ..

So, since my post from yesterday (see my numbers and link below), we have had 3 blocks signal "no" (1.8%) and the other 167 blocks signaled "yes" (98.2%).

As I type, we have about 97.98% of the blocks having had already signaled for taproot - more specifically - 1,258 out of 1,284 that have already been mined.

We also have ONLY 732 blocks remaining for the difficulty period and only 557 (which is 76.09%) have to signal for taproot to reach the 90% threshold (but who is counting?).

Very valid.  Yet I still think it is good, especially for the users who are not as keen about the details of past BIPs as well as development in general needed *this* particular upgrade to go smoothly.  I think it was palpably still tentative feeling out there because of all the drama in 2017.

Seems we are going to be dragging the shitcoins behind us possibly indefinitely, but it's becoming more and more dangerous for them to try to get in front of us.  The weight and momentum of Bitcoin is greater than it was a few years ago.