Topic: Empty blocks and max block size (Read 608 times)

Thats not what i learned. And even when you are true, the asics doesnt have to handle transactions. While the asics are calculating the master computer can handle the transactions and, when you are right, then only in rare cases a 1 transaction block will happen. When the block is found before the transactions can be gone through.

Processing the transactions has zero disadvantages for hashing speed. Of course, when hashing only starts when all transactions are gone through then there might be a disadvantage. But why should they wait? They can start mining and calculate transactions in the meanwhile, then, when ready, hash on these.

No.
They happen because miner pools start to mine new block (give tasks to asic miners) from the empty list after receiving block from peer.
They do not spend time for processing it and filling the list from mempool.
They try to increase their profits.

The advantage lies in the propagation time. If a miner finds a block then he is only safe that this block will be the real one when he gets >50% of all nodes convinced that this block is the real one. When another block gets >50% faster then the first block gets orphaned. Its worthless then.

The advantage of propagating a tiny block is big. You need to convince thousands of nodes that are only connected through p2p. Sending a block through all of them, one to the next, takes a lot of time.

I have read these miners have a 1% advantage because of that.

Youre right. The blockhalving will work in that direction too. Fees will become a bigger part of the reward. But it will take alot of time until thats the case. Though at least fees will be worth double of its percent value for each reward halving. So i think with adoption and fees on current level, we might see more and more 1 tx transactions.

I know what you mean, SPV mining. And i only now realize that competing pools can attack other pools that spv-mine by providing wrong block infos.

But what i meant wasnt mining on header data but building a queue on nodes.

Something like that:

Miner A mines 1 TX blocks.
Miner B mines full blocks.
Miner B finds a block, he propagates the headers to the nodes he is connected to. All nodes spread the headers to others and set this headers on top of the queue.
In the meanwhile the big block from Miner b propagates slowly.
Miner A finds a block. His block is very small. He spreads his header data. Nodes receive them and put them on position 2 in queue.
The block from miner A gets to all nodes. He gets verified completely and is valid. And the headers match that were previously sent.
The block from miner B gets in later. He gets verified and is valid. Headers match too.

In that situation the block from miner B would have been orphaned when his big block gets propagated to >50% of the nodes later. But with the queue the nodes would know that that block actually was found earlier and the block from miner A would get orphaned instead.

That way the advantage to mine empty blocks will vanish and the network will work more healthy. A big problem with more and more miners creating such blocks will diminish.

When a node receives information about a newly solved block it will update itself.  It will create a new block to solve with the transactions it has already received.  This process should take fractions of a second.  Then the process of mining the block (trying to solve the block it created)  begins.

According to my logic there is no advantage to creating an empty block to solve. And the miner misses out on the small amount of transaction fees.

Correct me if I am wrong?

The high subsidy we have these days distorts the market created by fees. Once the subsidy goes down to 6 or 3 BTC, miners will no longer have any incentive to mine empty blocks. They are going to need to include transactions or just lose money.

I don't think that the 20MB blocks will be an issue... I don't see blocks getting bigger faster than internet lines being updated. The change will be gradual, we won't have 20MB blocks the day after implementing the change.

As for headers first mining... That's what many are already doing, and that's why some pools forked. As you said, a timeout must be implemented, as very well written in this post, and well explained in the rest of the thread.

That's a good point.
Considering the "1 tx blocks during stress tests" found by Chinese miners (f2pool found 2 blocks in a row etc). This's gonna be huge problem.

Maybe someone can ask my questions.

So the empty blocks, or 1 transaction blocks, happen because a so small block will be propagated very fast through the nodes. Means 1 MB blocks might have a hard time reaching >50% and might get orphaned often.

When we now get 20MB blocks at one point, shouldnt the problem worsen then? I mean i can imagine the incentive to mine 1 transaction blocks will be even higher because the p2p speed wont keep up with that i think.

* Wont this be a problem?

Maybe a solution is to spread headers first, so some data identifying a found block. These headers are spread through all nodes in light time. The blocks follow later and can be verified. A one transaction block verified faster gets still orphaned when a 20 MB block gets verified later. That would ensure that empty blocks are not worth it.

There would need to be a timeout. Spreading faked headers wouldnt help because they would need to match a found block.

* Will this be a solution?

Then... when the spam happened, why did miners chose the huge transactions over many small ones with smaller fees? Shouldnt they chose many small transactions and shouldnt they be able to put more transactions with more fees into the block that way? Or only use the blocks that have the highest fee per satoshi. It shouldnt go after the fee per transaction because big transactions use much space and propagation time. It doesnt make so much sense to chose huge transactions that slow down a block and prevent more transactions being implemented only because they have a higher fee than small transactions. Though maybe its already handled that way.

* How is it handled and if not so why?

And what someone mentioned today... when we really want adoption we might need to drop the idea of a max block size completely and implement something like fee per output, since in fact each is its own transaction and should be treated like that. Since no post office allows you to bring 100 letters in a big box and send them out to 100 locations for 5 times the price for one letter. No, you either can chose the price of 5 times a letter to ship all letters to one location or you pay the price for 100 letters. I dont see a reason why bitcoin shouldnt handle it the same way.

* Is there a good reason to prefer transactions with many outputs?

Why? What happens when amazon decides to accept bitcoins? We might get flooded with transactions and might have filled our max blocks pretty fast. We would fail at the end maybe because a fork cant be made fast enough. So i think in order to allow adoption the max block size idea has to be dropped.

* What do you think about this potential adoption hinderness?