Is there a minimum block size?

[0mzUBBru]

Hello,
I just read the Bitcoin paper, and now I'm puzzled if there is a minimum block size for blocks to be accepted by the network.  If not, what is the incentive to add transactions without a fee to a block?

[1714788161]

1714788161

[1714788161]

1714788161

[1714788161]

1714788161

[1714788161]

1714788161

[1714788161]

1714788161

[1714788161]

1714788161

[willphase]

Thee is no incentive to include transactions without a fee when solving. However the reference implementation does add transactions smaller than a certain size for free, and since everyone is running this, they do get processed. It would be easy for the major pools to just change this in their code and stop processing transactions,.but the idea behind bitcoin is that network qos is agreed by consensus.

What's special about this mods is that, unlike e.g. just boosting the number of btc you earn per solved block, or lowering the difficulty, not processing transactions is perfectly within the right of a block solver and the blocks wouldn't be rejected by the network.

Will

[0mzUBBru]

What's special about this mods is that, unlike e.g. just boosting the number of btc you earn per solved block, or lowering the difficulty, not processing transactions is perfectly within the right of a block solver and the blocks wouldn't be rejected by the network.

Do you suggest, that I can solve empty blocks and they would still get accepted?

[willphase]

Yes I believe you could just solve empty blocks, and just include the 50BTC transaction, and they would be accepted by the network.

But remember you would still need to include the hash from the previously generated block (the blocks are linked) so if you thinking of some kind of offline solver, that wouldn't work.  Its in your interest to take the transaction fees from including transactions in your solved block, given you have expended a lot of effort to solve it.

Will

[willphase]

Also, I should add, right now there is alot more incentive to not include transactions... because the fees are totally outweighed by the generation BTC 'bounty'.

e.g. look at latest block 131205.

That's the 50BTC bounty and then 0.1 BTC from fees, which is less than 1% of the profit of solving that block from fees.

However, in a few years (2020) when the bounty for solving has dropped to around 6, and hopefully the number of transactions flowing through the bitcoin network has grown (conservative estimate, 10x) that's 6BTC from bounty and 1BTC from transactions, so now over 15% of your income as a miner is from fees... (and it continues like this, until 0 bounty from solving in 2033)

Will

[0mzUBBru]

So if somebody is just after the 50 BTC and does not care about the network, would he get a (maybe very small) advantage to just ignore transactions altogether? Like:

 * If I learn about a transaction, just ignore it (saves me memory, and if I do not tell others about it, bandwith)
 * If I learn about a new block, I try to build a new block on it with just the 50 BTC transaction

I guess, this optimization is small.  But it would reduce the complexity (LOC) of my client, which may be useful for further optimizing it.

Would a minimum block size or a minimum required number of transactions per block be useful?

[willphase]

So if somebody is just after the 50 BTC and does not care about the network, would he get a (maybe very small) advantage to just ignore transactions altogether? Like:

 * If I learn about a transaction, just ignore it (saves me memory, and if I do not tell others about it, bandwith)
 * If I learn about a new block, I try to build a new block on it with just the 50 BTC transaction

I guess, this optimization is small.  But it would reduce the complexity (LOC) of my client, which may be useful for further optimizing it.

Would a minimum block size or a minimum required number of transactions per block be useful?

yes the optimisation is small, but you could do that if you wanted, but if your client caught on and everyone started using it, then no transactions would be being verified and the network would collapse.  The only cost is the extra complexity of the client, it's no extra real cost to include transactions and you are getting the fees.

There is no minimum block size or number of transactions because the rate at which blocks are generated is determined by the difficulty and nothing else (in order to get around 6 blocks an hour) - having a minimum size would have broken bitcoin early on when there weren't many transactions going around.  Also, there is no way of knowing if the next block will be solved in 0.00001 seconds after the previous one (e.g. someone is very lucky) and we wouldn't want the protocol to break just because of edge cases like this.

Will

[0mzUBBru]

There is no minimum block size or number of transactions because the rate at which blocks are generated is determined by the difficulty and nothing else (in order to get around 6 blocks an hour) - having a minimum size would have broken bitcoin early on when there weren't many transactions going around.

I agree with you, that this was a good idea for bootstrapping the system. But is it still a good idea to allow empty blocks now?

Also, there is no way of knowing if the next block will be solved in 0.00001 seconds after the previous one (e.g. someone is very lucky)

I know what you mean, but 0.0001 seconds seems very unlikely to me, because you have to learn about the previous block, first (I assume that you meant, that the second block is built on the first one, here).  Still it would be theoretically possible, if you solved the previous block yourself.

and we wouldn't want the protocol to break just because of edge cases like this.

Do you think, that e.g. a requirement to include 10 transactions or some KB of transaction data would break the protocol today?  And if yes, how?

[willphase]

Do you think, that e.g. a requirement to include 10 transactions or some KB of transaction data would break the protocol today?  And if yes, how?

well you have to look at this from a holistic viewpoint.  The positives of making this change are... clients are easier to write, encourages people to include 0 fee transactions (in order to reach the minimum size).  The negatives are that it does mean that it's now possible to solve a block, but find that there are not enough transactions on the network to create a valid block, so your work has been wasted.  In addition seeing any kind of arbitrary limit is risky in my view - the benefits of doing this would have to outweigh the disadvantages, and I personally don't see that.

I just don't think making changes to the way the protocol is designed is wise unless there is a seriously compelling reason to.

Will

[0mzUBBru]

The negatives are that it does mean that it's now possible to solve a block, but find that there are not enough transactions on the network to create a valid block, so your work has been wasted.

Just to make sure that we are talking about the same thing: I assume that you need to know all transactions that you include into your block before you start the proof of work.  Please correct me, if I'm wrong.  So I do not see the point of wasted work.

Cheers, and thx for the chat so far

[ihadanny]

Just an idea - even if the minimum block size amendment passed, I could still include transactions from myself to myself to make the block kosher, right?

[theymos]

There's no way to enforce a real minimum block size, since miners would just send transactions to themselves, and there'd be no way to detect it.

Adding transactions to blocks has a small one-time cost. It does not increase the cost of every hash attempt. Nowadays you'll make enough from fees for the extra cost to be worth it. Allowing free transactions might increase BTC adoption enough to warrant the tiny cost, though some miners do reject all free transactions.

[JoelKatz]

Just to make sure that we are talking about the same thing: I assume that you need to know all transactions that you include into your block before you start the proof of work.  Please correct me, if I'm wrong.  So I do not see the point of wasted work.

The whole point of the block is to secure the transactions in it by piling proof of work on top of the transactions. Before a work unit can be assigned to a mining program, the previous block and the set of transactions to be included in the generated block must be known.

Generally, if a new transaction is received, it will be included in future work units assigned to miners. Past work units are still valid, and if they result in mining a block, the new transactions will not be in it. This means that when assigning work units, a record must be kept of each work unit assigned to a miner to allow the correct set of transactions to be bundled in the block should the miner succeed.

Also, as long as I'm responding to this thread, I should point out that long-term, every miner has an investment in the bitcoin system itself. If miners don't include transactions in their blocks, the value of the bitcoin system as a whole is reduced. Anyone who mines a block today has a good chance of mining blocks in the future and has a stake in maintaining the future value and stability of the system as a whole.