Share your ideas on what to replace the 1 MB block size limit with

[smooth]

Edit: With respect to CryptoNote and Monero, I do see merit in the argument that the fee penalty alone may not be enough to constrain blocksize; however when combined with the difficulty increase requirement the picture changes. As for the specifics of the Monero blockchain there are also other factors including dust from mining pools that led to the early bloating, and we must also keep in mind the CryptoNote and Monero also have built in privacy which adds to the blocksize by its very nature.

Yes, its complicated— but it's also concerning. The only altcoins that I'm aware of which have diverged from the current Bitcoin behavior in this front, and did so with the benefits of all the discussions we've had before being available to them, have been suffering from crippling bloat.

Glancing at block explorers for Monero and ByteCoin... I'm not seeing crippling bloat right now. I see lots of very-few-transactions blocks.

Glancing at recent release notes for ByteCoin, it looks like transactions were not being prioritized by fee, which is a fundamental to getting a working fee market.

Have Monero and ByteCoin fixed the bloat problem, or did the transaction spammers just get bored and go away?

Sorry for the late reply. I wasn't aware of this thread discussing Monero.

There was never any "crippling bloat." I'm not even sure what gmaxwell is talking about. There are certainly some forward-looking concerns about the future size of the blockchain (as with Bitcoin). But as of today there is no crippling. I run a Monero node on a smartphone-class nettop (just to see if I could), and it works fine.

There have been some growing pains. Early on the release one pool code didn't have a minimum payout threshold, so pools paid out on every block. Obviously that increased the volume of transactions, but the network still functioned normally and required no adjustment (save for fixing the pool code). And there was recently a spam attack on Monero and we responded by raising the (previously unrealistic <0.01 USD) default fee, but that only lasted a day or so and added 20 MB to the blockchain before the higher fee kicked in and the spammers stopped. Finally, the on-disk format is currently inefficient, and is being improved.

Still none of these issues have been crippling at all.

[jl2012]

Thanks for David Jerry bringing this up (https://twitter.com/digitsu/status/809152914023251968 ). Here is my reply

1MB-block supporters have 2 major arguments: decentralization and block space scarcity. By considering ONLY these 2 factors, however, the BEST solution is to limit a block to only 2 transactions: a reward transaction and a normal transaction. This will limit the block size to absolute minimal, and make sure everyone could mine with a 9.6k modem and a 80386 computer

Yes, if we consider ONLY these 2 factors, this is the best solution. But the very obvious fact is these are not the only factors

The truth is that the 1MB limit was just an arbitrary choice by Satoshi without any considering its implications carefully (at least not well documented). He chose "1" simply because it's the first natural number. Had he chosen 2MB instead of 1MB, I am pretty sure that Bitcoin would have worked in exactly the same way as how it works now. Had he chosen 0.5MB, we might have already run into a big trouble.

Yes, I still think 1MB is an arbitrary limit. If Satoshi used 2MB, Bitcoin should have worked in exactly the same way as it was in 2014 (when I wrote the original message). However, if we had 2MB today, without all the optimization brought by Bitcoin Core in the past 2 years (libsecp256k1, compact block, pruning, etc), many full nodes would have been broken.

Had he chosen 0.5MB, it might be easier for people to reach consensus to increase it. However, I have to say the effect of hitting the limit is not as bad as I thought. One indication is the robust price uptrend in this year. OTOH, most tx confirmation problems are related to wallet design.

We want to maximize miner profit because that will translate to security. However, a block size limit does not directly translate to maximized miner profit. Consider the most extreme "2 transactions block limit", that will crush the value of Bitcoin to zero and no one will mine for it. We need to find a reasonable balance but 1MB is definitely not a good one. Assume that we aim at paying $1 million/block ($52 billion/year) to secure the network (I consider this as a small amount if Bitcoin ever grows to a trillion market cap). The current 7tps llimit will require a fee of $238/tx, which is way too expensive even for a global settlement network among banks.

Note that when I say "1MB is definitely not a good one", the context is bitcoin would become a global settlement network with a trillion market cap. I think my estimation is still correct, but this is a long term vision.

To answer the question of "what to replace the 1 MB block size limit with", we first need to set a realistic goal for Bitcoin. In long term, I don't think bitcoin could/should be used for buying a cup of coffee. To be competitive with VISA, the wiki quotes 2000tps, or 1200000tx/block, or 586MB/block (assuming 512bytes/tx). To be competitive with SWIFT, which has about 20 million translations per day, it takes 232tps, or 138889tx/block, or 68MB/block. Divide them by the $1 million fee/block, that would be $0.83/tx and $7.2/tx respectively. A fix rate of $7.2/tx is a bit high but still (very) competitive with wire transfer. $0.83/tx is very competitive for transactions over $100 of value. I think a reasonable choice, with the implications for centralization considered, would be around 100MB/block. That takes 1.5Mb/s of bandwidth in a perfect scenario. That would be a better equilibrium in technical and economical terms.

This 100MB estimation does not take payment channel like LN into considerations. It also doesn't take better cryptography like Schnoor signature aggregation (saving lots of block space) into considerations. Schnoor signature alone could easily cut my estimated size by more than half (and it is totally on-chain). With more optimizations (weak block, UTXO set growth limit, fraud proof, partial block validation by SPV wallet), I don't think 50MB blocks is an insane idea. It just can't happen today.

Finally, as a not-so-related note, one may also note that I'm always a fan of softforks since I joined this forum, for examples:
https://bitcointalk.org/index.php?topic=283746.0
https://bitcointalk.org/index.php?topic=256516.10
https://bitcointalk.org/index.php?topic=253385.0
https://bitcointalk.org/index.php?topic=1103281.0

[Jet Cash]

There are some great replies inthis thread.

The impression that I get is that there are a number of objectives that have been discussed ( blocksize is a possible solution and not an objective).

- Speed up transaction confirmation for end users
- Reduce bloat in transactions
- Reduce the number of records required for each transaction
- Maintain the de-centralisation of mining.

At the moment block generation time is too long, and it can result in transactions taking up to an hour to be confirmed. Bitcoin won't remain competitive if this continues, or gets worse. I read the replies to my thread suggesting a reduction in the generation time, and I am grateful for the informed comments, and I accept the reasons for not reducing the time in the current environment. I think it is desirable for better minds than mine to address this problem to see if there can be a way to reduce the generation time.

Reducing bloat in transactions - one way to do this is to REDUCE the blocksize, maybe to 500K, and combine this with faster block generation. Obviously this is subject to the constraints mentioned above. SegWit should be  great help with this as well.

Reducing the number of records - there was an interesting suggestion about combining micro-payments  into one transaction within a wallet. It would be useful if this could be done with a zero fee transaction, but would miners be prepared to support this. There is not the same priority for the confirmation of these consolidations, so maybe they could wait for anything up to a week, Listing them in a consolidatation pool after they have been verified could give miners a handy alternative to mining empty or near empty blocks. This would help to speed up future payments from that wallet, and it would reduce the number of transactions waiting to go into a block. You wouldn't need a fork for this, as miners not supporting it would just ignore the second pool, and those who did support it would create blocks that were valid under the current rules - is this true, or am I misunderstanding the block filling process?

Maintaining the decentralisation of mining. I accept the point that reducing the block generation time can create "churning" of the blockchain, and would give larger miners an advantage when the block generation time is minimal. If it were possible to enforce a minimum time for the generation of  a new block ( say one minute) then surely that would cut out much of the churning, and may even attract a few small miners to return to mining.

Side chains are also beneficial, and maybe we can explore the way to increase their use more effectively. Maybe all faucet payments should be moved onto a specialist side chain for example.