Please login or register.

Increasing the minimum block size

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
nioc posted 8 years ago Weight: -110 | Link [ - ]

It looks like the 60 KB was just added to GitHub

Reply to: luigi1111 papa_lazzarou
papa_lazzarou posted 8 years ago Weight: -110 | Link [ - ]

Yeah. I don't know what I am doing here. I just found out I have a ISFP or INFP personality. Which, on the face of it, makes sense, really. :P

> group by payment ID within X blocks

I think I can do that. Guess what? I'll not even be thinking about it. I'll just start writing the query now and see where it goes. I guess I'll get it OKish after 400 iterations...

Oh well

Reply to: smooth EhVedadoOAnonimato
EhVedadoOAnonimato posted 8 years ago Replies: 1 | Weight: -99 | Link [ - ]

Ok then. Please let me know when Monero stops being an experimental toy used geeks and becomes and actual usable system, in production. I mistakenly thought that already was the case, since people are already paying actual money for XMR.

Sarcasm apart and talking seriously now, my points above remain. I'd still like to see a rebuttal to them, and more importantly, to the comment I've made in the other thread, where people argue about increasing the time interval between blocks. I like the 1 min interval and I'm not convinced that needs to change. Thanks.

Reply to: EhVedadoOAnonimato smooth EhVedadoOAnonimato
luigi1111 posted 8 years ago Weight: -99 | Link [ - ]

If we launched Monero today, we definitely wouldn't choose 1 minute for the blocktime. Why should we be stuck with it now? Because "we don't change important parameters in a working system"? I reject that wholly presently (for non-"social contract" stuff). If Monero grows, changing stuff will definitely get harder (rightly and reasonably so). We are nowhere near there yet. While we have the freedom to change stuff like this for the better, I think we should definitely go for it.

For the minimum median size, it's basically a bandaid, sure. But this bandaid will help out payment processors and users significantly in these early days of low, low usage, with very little (or no) obvious ill effects likely to arise. If transaction use rises to moderate use, it'll become almost entirely irrelevant anyway. There's even a possibility the blocksize adjustment algorithm could be changed to something significantly different (but better!) later.

Back to blocktime: this was another "genius" parameter chosen by TFT that basically no one agreed with. It was, and is, subpar. Fortunately, unlike the emission, nothing prevents us from changing it to something better (anything longer within an OOM or so being better). 1 minute confirms aren't "fast", nor are they secure since reorgs happen very frequently. I think you mentioned something about reorgs being fine because transactions will probably be confirmed on both chains. This is irrelevant because honest transactions you trust to "be there in both chains" you can trust even before they're in any chain. 1 minute blocktime is also a significant pool centralization pressure (much, much more than Bitcoin's configuration, and we know how much people talk/worry about that); it's almost like purposely encouraging it.

I do agree that "less coinbase transactions" will be mostly meaningless if usage takes off, but that doesn't mean it isn't beneficial now, when usage is low. It's kinda like this Satoshi quote: "It would be nice to keep the [blockchain] files small as long as we can. The eventual solution will be to not care how big it gets." Less blocks/coinbase transactions will certainly be beneficial now, allowing faster syncing/better experience for new users/etc, which may even be a contributing factor to increasing Monero's usage to the level that it's irrelevant!