Bitcoin Forum

i am parsing blockchain and came to this strange block.

Block #503198


ref: https://blockchain.info/block/00000000000000000011b4db68e2f052572fdfd93c8293257b7727429f5418b9

and lots of questions came to mind.

why this block has only 1 tx ?
its not like beginning days of bitcoin when only 1 tx used to be there in a block, there are backlog of 100k+ tx and why this block only has 1 tx ?

all previous and later blocks has 1k+ tx in them, then why is this block empty ?

what am i missing here ?

thanks for your time.

The protocol leaves it up to the miner to decide which transactions to include in a block. There is no requirement for them to include any transactions at all, other than the "coinbase" transaction which specifies where to send the block reward.

However, most transactions have fees attached, which the miner can collect only by including those transactions in the block. So this gives the miner an incentive to include transactions if there are any outstanding.

Note that a block with no transactions does still contribute to the security of the currency: it increases the amount of hashing that an attacker would need to do to reverse a transaction recorded in a previous block.

(They would have to produce a chain showing more work than the current one, including the work proved by the zero-transaction block.)

whats the use of such block ? if they are not helping network to reduce the unconfirmed tx ? they are only making it hard to reverse the tx or providing their hashpower.

so what needs to be done to mine such block ? what do you tell your miner ? not to include any tx .

what happens when more people start to do same thing ., and not include transactions in block ?

i gotta read more stuff now, all this time i missed it, block can be empty too, then what is block made of ? how is the coinbase tx gets created/generated.

dang.

edit:

looks likr consensus is what i need to look into.

block = coinbase tx + regular tx (optional)

coinbase tx gives block reward
regular tx gives tx fees.




thanks .

Some miners have mining code that works like this:

If they solve a block very quickly after the previous block N (i.e. only a few seconds later), then they simply relay an empty block N + 1 (there's only one transaction because a single transaction is the minimum required to pay the block reward to their mining address).

The rationale is that if they wait for their mempool to re-sort the remaining transactions, they risk some other miner solving block N + 1 during the time it takes to choose the transactions to include in their solution for block N + 1. Since the block reward is still fairly high in comparison to fees, this is considered to be an economic strategy.

Thank you for this.

Personally I thought it had more to do with transactions in the queue rather than miners picking and choosing.

Absurd. Nonsence. Very poor understanding from legendary forum user  :'(

enlighten us

No, he was spot on actually. When the previous block has just been found other miners may not have yet had the new block relayed to them so they do not know what is included in it. If they include transactions in their block that were in the previous block it would be rejected as invalid. In that situation, they will mine an empty block to claim the block reward.

https://news.bitcoin.com/reason-bitcoin-miners-empty-blocks/

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

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

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

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.

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.

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!

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.

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.

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

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

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.

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.

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.

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.

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)

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.

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

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!

wrong!
totally wrong!