Block #503198 what is it ?

[DannyHamilton]

amaclin, you made an abrupt decision to start distinguishing between ASIC software and mining software, which are indeed different,

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.

[Carlton Banks]

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.

[-ck]

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.

[Carlton Banks]

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.

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

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.

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)

[-ck]

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)

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.

[Colorblind]

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

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

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.

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

[zorro_tolerant]

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

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!

[amaclin1]

It is almost impossible to make 51% after 9 years blockchain history and >500k blocks generated...

wrong!

You basically need to re-compute all the hashes having higher CPU power than all miners in the world!

totally wrong!