Topic: Empty transaction blocks (Read 2472 times)

There are at least two ways that empty (1txn) blocks can be used.

The first is concerned with reducing idle time. If a block is solved and broadcast to the network then as a miner you are first made aware of the block header. This block header is all you need to start mining the next block. The rest of the block may take some time to propagate and will also take further time for you to validate and adjust your mempool. There is a chance that during this time you may find a block. Given the block reward is high and fees are low the most profitable thing to do is publish the block immediately. As you have not yet validated the previous block you cannot know which transactions to include from the mempool, so the only transaction you can include are ones that you know nobody else knows about - typically the coinbase transaction.

The second us a natural disincentive for miners to produce blocks that are too expensive to propagate/validate. If such a block  is produced then a miner may decide that validating this block is taking too long and instead decide that they could make more profit by mining a smaller sibiling block. This block would also be seen by miners and they could decide whether to continue validating the "expensive" block or instead mine on top of the easy to validate block. These behaviours form a natural equilibrium in block size obviating the need for any artificial limit.

From what I can gather their miners begin work on the next block before the pool has decided on the txs (so they are broadcasting the block header as soon as they see a new block seemingly without even validating the new block much which is what led to the block version fork).

Presumably they then later send out the block header for the block that actually does have the txs included (and perhaps after further validation of the new block although I am only speculating about that) but if a miner had already found a solution with the previous (empty apart from coinbase) header then they will publish that (thus typically these blocks are found very quickly).

If indeed this is how it is working then I guess it isn't really having as big an effect upon TPS as otherwise it might.

I just do not understand this empty block thing.  What is it they are doing to cause this specifically?

This thread was moved from another non-mining part of the forum, and moderators dont have a merge function. Maybe in ten years whenever the new forum software gets finished we'll have the option.. but this is all offtopic banter.

I wonder why -ck didn't merge this with my empty block thread.  At any rate, you ask very pertinent questions Preclus.  We recently had a very large backlog of unconfirmed transactions floating around.  People flooded to the forum asking why their transactions were not getting confirmed.  There was plenty of bad press produced claiming the bitcoin network was doomed.  Claims were made that block size absolutely needed to be increased immediately.

If you read my empty block thread you'll also notice how many single transaction (only the coinbase) blocks are added to the chain.  During that time we were experiencing a backlog of transactions, had AntPool produced only half as many empty blocks as they did, there would not have been a backlog.

So, does this have an effect on transactions per second?  Absolutely - at least from a throughput point of view.  Let's assume that in order to maintain parity, I need to consume a throughput of 1500 transactions per block.  Obviously if one or more actors are cheating and not putting any transactions in their blocks, then the overall throughput rate goes down and transactions become backlogged.

I've been urging people to stop mining on pools that produce empty blocks and move.  Yes, I run my own pool and would love to see more miners on it.  However, it is more important to have miners stop pointing their hash to the bad-for-bitcoin pools, and there are plenty of choices out there, including, but certainly not limited to my own.

401870 - 1m29s Full block
401873 - ~3mins Full Block
401879 - ~5 mins Full Block
401882 - ~2mins Full Block

There are other short blocks that were filled if you look for them.

401582 14:50:11 / 401583 14:50:36 = 21 Seconds
401556 10:03:58 / 401557 10:04:39 = 41 seconds
401538 07:35:40 / 401539 07:36:39 = 59 seconds
401511 02:48:24 / 401512 02:48:52 = 28 Seconds

I will say I stand corrected on not seeing empty blocks but all the above were no where close to the estimated 10 minutes per block that the ecosystem that bitcoin is based on.  I do agree some more diversity as to the pool would be good for bitcoin.  After all I have a pool and am running core 0.12.0 over classic or the other options.  People are never going to leave the big pool though and loose the constant dust that they are getting. 

Not necessarily. Look at ckpool. They do full verification of blocks and produce very few empty blocks and have few orphans. With a dedicated server and decent setup and software, the time to verify a block to begin mining on it is negligible.

Horse shit. Only Chinese pools use SPV mining. The alleged benefits you list there are no more than propaganda. Other pools get by fine with full verification of blocks and transactions on new block generation without delays getting work out to miners, nor an increase in orphans.

Maybe this might help:


https://blockchain.info/block-height/401583
https://blockchain.info/block-height/401557
https://blockchain.info/block-height/401539
https://blockchain.info/block-height/401512

(very recent and all from AntPool)

If you find a block 30 seconds after another block is found and there is no backlogged que at all maybe.  Its been a long time since i have seen any empty block.  I have seen some small ones but not empty.

Whilst it is true that mining an empty block can be done faster as the block reward diminishes the omission of txs for the slightly better chance of winning the block reward becomes less attractive (so after the next halving one would expect to see fewer such empty blocks and even fewer after the following halving, etc.).

This is what is described as the "fee market" and will eventually be the only reward that miners will receive.

The size of the block doesn't matter but you can start solving for an empty block before you can start solving for a block with transactions.

Described in the thread referenced above:

Why do some pools do that? Is there an advantage?

Time.  Get the details of the last block mined, immediately start mining for the next - at this point 'empty' - block (and your chance at the block subsidy).  Then while things are busily mining away, build new headers that do include transactions, and at the next opportune moment start mining on that. It's just a small sliver of time, but against an otherwise equal opponent, collecting transactions by default would be a losing strategy in the long run.

No. The size of a block does not matter in how quickly the block is solved. A block with no transactions and a full block both have the same probability of being the solution.

So, if it does decrease the effective TPS rate, at some point is it an effective limit on the blocksize as well? Or is the effect of empty blocks constant with respect to blocksize? If it does effectively limit the blocksize, what is the limit?

Obviously empty blocks means that txs that otherwise could have been in those blocks are instead sitting in the memory pool (delaying their confirmation and reducing the effective TPS rate).

It is interesting that the CEO of AntPool has recently made public his support for Bitcoin Classic (and 2MB blocks) yet their pool is the one responsible for nearly all of the empty (1 tx) blocks at the moment.

(if he is really of the opinion that we need larger blocks now you'd think he'd bother to have his pool fill up the blocks that they are mining currently)

That is all made clear in the thread I referred to above [ correction: thread other poster referred to]. I suggest you read the full thread if you haven't. One of the arguments for mining empty blocks is to prevent double-spend. But the argument is specious and the real reason seems to be miners trying to gain advantage for themselves.

My question stands: Does allowing empty blocks effectively put an real-world limit on the blocksize?

Modern Bitcoin mining is very different than years ago.


All pools use SPV mining. This means miner believes a new block header is valid and mine upon it.

This reduces orphan risk. During the period a whole block transactions are buffered, the receiver mines an empty block.


Why empty block? To avoid accidental double spend /double confirm. Double spend could cause the miner to lose funds from the reward due to block becoming invalid.


The block size is not as relevant anymore, but orphan risk is still present during the one second or so latency window after mining a block.

EDIT:

Please, stop reading some discussions, and study how the system actually works.


You don't know how Bitcoin actually works.

The stackexchange links didn't have much information but the discussion in the bitcointalk mining group had a decent discussion and a lot of data. Thank you for posting it, I hadn't seen it before. There are a few discussions on reddit about it but for the most part, it didn't seem there was any consensus on how it affected the network.

My question still is.. don't zero transaction blocks effectively limit the blocksize?

For example, I would guess you couldn't have a blocksize of 100MB as large miners would publish zero transaction blocks, maybe even multiple zero sized blocks, to orphan other miner's work while they work on making a longer chain. When the block transaction time gets long enough, it seems like the system would break down. And that orphaned work decreases the hashing rate of the entire network. So, these types of transactions seem to artificially cap the total number of transactions and thus the "effective blocksize"?

Or do zero transaction blocks cause a decrease of the effective hashing power of the network that is constant against increases in blocksize?