Topic: Block #503198 what is it ? (Read 513 times)

wrong!
totally wrong!

It is almost impossible to make 51% after 9 years blockchain history and >500k blocks generated...
You basically need to re-compute all the hashes having higher CPU power than all miners in the world!

Thank you for this correction. It brings more clarity to my understanding.

Definitely. In essence they're still mining on just the header of the first block they solve since they can just get out a blank template for work while waiting for the bitcoin daemon (or whatever custom block generator they use) to create a fresh block template for them and then the pool software to distil it down into a merkle tree they need to then send out. It also saves a few bytes but that doesn't matter much since all the current mining protocol messages easily fit into one MTU - though the likelihood of need for retransmission increases as the size of the packet gets larger.

I forgot about fibre. So compact blocks is not a factor at all today? (in propagation performance for mining)



Ah, so this is not so much a performance-gain based strategy, but more a performance mitigation strategy? Would "To-Big-To-Scale" pool software also account for the same pool mining 2 consecutive blocks, the 2nd of which is empty? (I seem to remember Antpool recently mining 1 full block quickly followed by an empty block just recently)

It goes beyond the time taken to sort transactions in the bitcoin daemon to generate a new block template which is an issue in itself and has to work within the limits of scalability of the pool software as well and its ability to send out fresh work to thousands of miners.

Pools also have clients connected to other pools in order to detect a block that has been solved by that pool before it has even propagated on the network based on the block header sent in their stratum (mining protocol) template for new work. As they don't have the full block but have the header they cannot even build transactions on it but can start working on a transaction free template until they get the full block and then create a template for work with transactions afterwards. This is one of the main reasons blocks very close to each other from different pools do not contain transactions. This is also why there was an invalid fork that many pools were mining on for an extended period a couple of years ago - they forgot to check the block was ever valid. They've at least fixed that issue but they will still keep mining empty blocks.

None of my pools or pool software do any of the above since speed and scalability was the reason I wrote new software from scratch so there is very little to gain by doing so, and I've always believed in only mining on fully validated blocks and mining as many transactions as possible. Thanks to Bluematt's fibre network it doesn't take long for full validated blocks to propagate any more and bitcoin core's block template generation is magnitudes faster than it used to be at sorting and creating new transactions. At best working on an unvalidated header can only gain 200ms these days. However that doesn't take into account that the pool software itself used by the bigger pools hasn't been able to scale to the number of clients they're seeing so they still save time in getting new work out to all the miners with an unvalidated block header based template for work.

You're missing the point really, Danny.

I'm not making distinctions between the specific nomenclature of software used in mining at all, as it doesn't matter when talking about the reason that empty blocks are created.

Suffice to say -

• mining pool software
• solo mining software
• hybridised solo/p2p mining software

...could all 3 be designed to mine empty blocks, under given conditions. What we're interested in is the conditions under which that happens, please read the OP.

And this is where discussions about the mining process frequently fall apart.

Unless all parties in the conversation have agreed ahead of time on exactly what they mean when they use various terms, it can become quite a mess.

When you say "mining software" are you talking about:

bitcoind (which has had mining turned off for several releases now)?

The software that the mining pool operator is running?

The software that the participants of a mining pool are running?

The software that a solo-miner is running?

These are all very different software with very different purposes and very different things that they do.

While I don't always agree with amaclin1's methods or opinions, he is generally correct when he is talking specifically about bitcoin technical facts.

I'm also aware that his responses to Carlton Banks and TheQuin were the result of changing from a generalized discussion of "miners" to a specific discussion of "mining pool hashing participants".

That being said, he is correct when he says that the (asic holder) does not have the transactions, and you are mistaken when you suggest that they do have the "block contents". I've corrected your response to him where I've quoted you above.

The miner (ASIC holder) typically does NOT receive the contents or transactions of the block. All he needs to do his job is the 80 byte header.  I haven't paid close attention to developments in pool mining, but I'm guessing that most modern pool mining doesn't even send the entire header?  It probably just sends the midstate after beginning the SHA256 hash on the first half of the header.

Miner receives block contents (transactions) from mining pool. It's not miner's job to form the block, his job is to calculate nonce.

P.s. by miner in this context I mean ASIC owner. Not canonical "Miner", that is actually made from pool+all ASICs.

I see, so how does the miner broadcast a block they solved if they never know which transactions to include since the last block? All blocks would be empty if that was true.


amaclin, you made an abrupt decision to start distinguishing between ASIC software and mining software, which are indeed different, in order to make a childish point about nothing except your tiny ego (that distinction has no relevance when explaining this phenomenon). Please don't return to the thread, you're not very helpful

Miner (asic holder) does not have transaction set ever! And mining software does not
switch automatically to block N+1 if block N is found somewhere in network.
I understand you lack of knowledge. Your explanations are very poor. Point. Good bye. I am out from this topic

If one defines block N as the most recent block, and N + 1 as the subsequent block to that, and that a given miner has a solution for N + 1, then said miner can successfully relay their solution for block N + 1. You clearly didn't understand my sentence, otherwise, you wouldn't be trying to imply I said something which I didn't say.


I guess that condition could still exist, compact blocks do not change the probability of solving blocks seconds after the previous block, and so there is only a marginal case where compact blocks improve the window of opportunity to win the propagation-race of a full block v.s. an empty block. I assumed that transaction re-ordering for a large mempool was the contemporary reason for empty blocks without considering this.

Simply that the miner finds the next block when he is aware of a new block but hasn't fully downloaded and verified it. It might be a very short timespan but there still is that in between period however fast your internet connection and processors are. Orphaned blocks are when the miner is totally unaware of the new block and as you say a very rare now.

English is not my native language too. The problem is in another place.
It it not possible to relay empty block N + 1 simply or hardly or any other manner
because block is not solved yet!

that means "the next block". English is not your first language, that's always been abundantly clear.




Hmmm, I discounted this specific situation due to how long BIP 152 (compact blocks) has been available, my understanding was that new blocks now propagate so fast that orphaned blocks (the result of trying to propagate new block solutions with transactions from a previous block) are exceptionally rare.

So, I figured that with such a big mempool these days, re-sorting transactions for inclusion would be a more significant factor than knowing which transactions are now invalid in a new block. But in essence, it's propagation latency issues (i.e. the block race) that cause miners to mine empty blocks. Which latency issues are relevant today, I am not completely sure of.

No, it was not, the answer has already been given above. Please take the time to read and learn something rather than just posting complete nonsense.

imho 51% attack is not that easy and why do something like that ? unless there are bitcoins worth couple of millions are at stake.

Maybe it was 51% attack ? I do not know how but this is the place to be, big amount of miners accept this version of block #503198

This explanation is much better (but not perfect either).

It does not cover the processes in the stratum protocol between pool and connected to it asics,
but at least it does not have the words "...then they simply relay an empty block N + 1..."