kano
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
June 12, 2021, 07:12:05 AM Merited by JayJuanGee (1) |
|
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
Legendary
Offline
Activity: 4354
Merit: 4704
|
|
June 12, 2021, 09:28:07 AM Last edit: June 12, 2021, 04:35:43 PM by 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
|
I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER. Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at
|
|
|
fillippone
Legendary
Online
Activity: 2296
Merit: 16462
Fully fledged Merit Cycler - Golden Feather 22-23
|
|
June 12, 2021, 01:31:33 PM |
|
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.mp4A big step in the protocol.
|
|
|
|
kano
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
June 12, 2021, 01:42:42 PM |
|
... 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
|
|
June 12, 2021, 04:36:11 PM |
|
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
Legendary
Offline
Activity: 1946
Merit: 1427
|
|
June 12, 2021, 06:08:55 PM |
|
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 (OP)
Moderator
Legendary
Offline
Activity: 4242
Merit: 8702
|
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
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
... 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) 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
|
|
June 15, 2021, 09:51:01 PM |
|
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?
|
Bitcoin is energy. Bitcoin is freedom I rather die on my feet than living on my knees!
|
|
|
achow101
Moderator
Legendary
Offline
Activity: 3500
Merit: 6840
Just writing some code
|
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
|
|
June 16, 2021, 09:34:57 PM |
|
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!
|
Bitcoin is energy. Bitcoin is freedom I rather die on my feet than living on my knees!
|
|
|
fillippone
Legendary
Online
Activity: 2296
Merit: 16462
Fully fledged Merit Cycler - Golden Feather 22-23
|
|
June 17, 2021, 12:32:37 PM Last edit: May 15, 2023, 11:41:26 PM by fillippone Merited by JayJuanGee (1), BrewMaster (1) |
|
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=21He 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
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
June 17, 2021, 11:51:22 PM |
|
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
Legendary
Offline
Activity: 3584
Merit: 10909
|
|
June 18, 2021, 03:31:34 AM |
|
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 (OP)
Moderator
Legendary
Offline
Activity: 4242
Merit: 8702
|
|
June 18, 2021, 06:49:20 AM |
|
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
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
June 18, 2021, 07:27:25 AM |
|
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
Legendary
Offline
Activity: 3290
Merit: 8625
icarus-cards.eu
|
|
June 24, 2021, 03:44:30 PM Merited by JayJuanGee (1) |
|
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
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
June 30, 2021, 04:31:07 AM |
|
Meanwhile, some noob pool shows up and mines a block without the taproot flag ... lulz.
Block 689182
|
|
|
|
pooya87
Legendary
Offline
Activity: 3584
Merit: 10909
|
|
June 30, 2021, 04:36:46 AM |
|
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 (OP)
Moderator
Legendary
Offline
Activity: 4242
Merit: 8702
|
|
June 30, 2021, 05:41:41 AM |
|
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)
|
|
|
|
|