Please login or register.
This location

Increasing the minimum block size

smooth posted this 8 years ago

smooth | 8 years ago

The minimum median block size is current 20 KB, meaning without the dynamic block size kicking in, any block can be up to 20 kilobytes without any miner penalty. In increasing the block time to two minutes it was initially proposed to increase the minimum median size to 40 KB, which retains the same rate of base block capacity.

It was later proposed to increase this to 60 KB, because of the observation that larger mix sizes will create more split transactions and split transactions are inconvenient for merchants, whose systems are often set up to accept one payment, and further sometimes find payments need to be processed manually due to various problems with split payments. 60 KB is observed to allow most routine payments to be handled without splitting.

So the current plan is to increase the minimum median block size to 60 KB. As a rate this is 300 KB per 10 minutes, so 30% of Bitcoin's maximum rate (1 MB/10 minutes), though of course Monero allows the block size to increase based on transaction demand. The minimum size reduces the resistance to spam attacks and increases the potential for more rapid blockchain growth relative to transaction demand.

It is not necessary to increase the minimum block size at all. In AEON when the block time was increased from 1 to 4 minutes, no increase in the minimum block size was made, and everything still works, with the block size dynamically increasing during high usage. However, this does not provide any relief from the need for many split transactions, and further AEON does not impose a hard minimum on mix factors the way Monero will (post-fork).

Open for discussion or feedback on the proposal to increase the minimum median block size to 60 KB.

Replies: 19
Reply to: luigi1111 Myagui
luigi1111 posted 8 years ago Replies: 2 | Weight: -123 | Link [ - ]

Transaction 1 (idealized case): 1 input (mix 4), 6 outputs (3 significant digits to receiver + change): ~648 Bytes

Transaction 2 (made up average case): 10 inputs (mix 4), 10 outputs: ~4,247 Bytes

Transaction 3 (pool miner): 200 inputs (mix 4), 10 outputs: ~74,637 Bytes

Transaction 4 (well used wallet with small change): 100 inputs (mix 4), 10 outputs: ~37,537 Bytes

In general I'd expect transactions to be slightly to moderately smaller than what I have listed, due to my (IMO generous) choice of varint lengths. I chose mixin 4 because that's what the client software defaults to now (AFAIK), and it should be the typical, supported case. IMO we don't need to support sky high mixins via the minimum median size.

Note that outputs don't have a very large effect on transaction sizes, so changing those from 6-10 to something else will not change much. Pools that cater to a large number of participants shouldn't have any trouble splitting their payout transactions anyway.

Reply to: Myagui
luigi1111 posted 8 years ago Replies: 1 | Weight: -123 | Link [ - ]

I don't think covering the "typical" case counts for much, if anything. I think we should shoot to cover 80-95% cases (or even more?).

Well actually your last sentence basically agrees with my sentiment, but seems at odds with your second sentence.

I can post up some sample transaction sizes, but don't have the experience to say how often these are actually occurring.

Reply to: Myagui
smooth edited 8 years ago Weight: -123 | Link [ - ]

It is certainly not the case that every "ordinary" transaction requires a split. Even with 3-5 mix you can still have transactions that are only 2 KB or maybe even less. It depends how many inputs are used. The issue seems to be that transactions that do require a splitting are not very unusual with the current size limit, so that creates problems.

Maybe fluffypony or others who run services can comment more specifically on how often problems occur and how the proposed increase would help.

Myagui posted 8 years ago Replies: 2 | Weight: -123 | Link [ - ]

I certainly agree with the principle of setting a minimum block size balanced with a sort-of-baseline transaction size.

It would be great to see some sample values to better understand what exactly is the typical transaction size for an average transaction using an average mixin count.

I think that the change is worthwhile, if we see that even a single ordinary transaction with average mixin would require a split (when block size is at its minimum).