Bitcoin's maximum block size

[examplens]

At the moment, Bitcoin does not serve as a currency for most anyway, but if the current fees are too high for someone, we have LN, which can be used in a very simple way with the help of some wallets (Phoenix Wallet).

That's true, although personally i find LN not attractive when you don't frequently make or receive payment.

Add to that, the vast majority still don't even know how to use LN, or it's more complicated than the "simple" copy/paste bitcoin address that everyone supports.

[Kemarit]

As you might know, Bitcoin sometimes got criticized due to relative high TX fee and small block size. Despite SegWit upgrade which allow a bit bigger block size (up to 1 vMB or 4 kWu/million weight), some people feel it's not enough and there's need for bigger block size. While other option such as LN and sidechain exist, there aren't many service or wallet which support either those. Now here are my question,

1. Do you support increasing Bitcoin maximum block size?
2. If yes, what factor should be considered when choosing new maximum size?

1. No, I think Bitcoin should remain as it is in terms of block size. It has proven already that it will create a lot of schism inside the community and we wouldn't want to go there again. And look at how many Bitcoin forks we had, block blockers but they don't have the support of the community and some of them even die a natural death.

2. No, refer to my first answer.

[ABCbits]

I think that if a way was found to make the block size dynamic as in Monero without the need to change the code and impose a penalty on the block reward when the block is larger, the scalability of Bitcoin would be better. The SegWit soft fork gave a better result than any hard fork. Instead of giving in to increasing the block size, it was increased. Up to 4M weight units with the size on the block size fixed. I don't know if there will be a soft fork in the future that will lead to better results.

But considering previous Ordinal spam, i wonder how well dynamic block size would work on Bitcoin network. And since Monero implement it without maximum size, i wonder how will Bitcoin community react.

1. No, I think Bitcoin should remain as it is in terms of block size. It has proven already that it will create a lot of schism inside the community and we wouldn't want to go there again. And look at how many Bitcoin forks we had, block blockers but they don't have the support of the community and some of them even die a natural death.

I get your point, although FWIW most Bitcoin forks only created solely for obtaining more money. That shows by some Bitcoin forks create some coin (out of thin air) during it's fork process.

[bitmover]

At the moment, Bitcoin does not serve as a currency for most anyway, but if the current fees are too high for someone, we have LN, which can be used in a very simple way with the help of some wallets (Phoenix Wallet).

That's true, although personally i find LN not attractive when you don't frequently make or receive payment.

Add to that, the vast majority still don't even know how to use LN, or it's more complicated than the "simple" copy/paste bitcoin address that everyone supports.

I have used LN several times recently, and I think  it is very complicated.  I don't trust a lot of money in it..

Easy to use wallets are also not that simple. I agree with examplens.. paste address is much simpler.

[garlonicon]

Do you support increasing Bitcoin maximum block size?

No.

If yes, what factor should be considered when choosing new maximum size?

Verification time, also known as Initial Blockchain Download time. If you want to increase the size of the block, then you can never go beyond verification time. Because if you will, then new blocks will be produced at a rate, where maybe you could download all of them, but never verify all of them. And as long as you have to verify the whole chain, to be 100% sure, that your new blocks meet all consensus rules, you cannot do much with the maximum block size.

Which also means, that if you want to seriously consider any increase, then you have to improve Initial Blockchain Download first. If creating a new full node wouldn't require verifying over 500 GB of data, from the last 15 years, then you could think about increasing the size of the block.

if the fees continue to rise such that it becomes difficult or impossible to use Bitcoin normally, then I think that both miners and society will agree to increase block size within a certain limits

There are ways beyond increasing block size, which could increase Transactions Per Second. One of them is transaction joining. For example: imagine that you have a lot of different coins, and for each of them, there is some public key, representing the owner. Imagine that the only information you need, is to know "who owns what", and you confirm it every 10 minutes. If you have a signature, which allows moving the coin from one public key to another, you can join a chain of signatures, and put only the last owner in the final block. Which means, that if you have a coin, which is owned by Alice, and then is passed into Bob -> Charlie -> Daniel -> ... -> Zack, forming a chain of unconfirmed transactions, then you don't have to record all of those transactions in the final block. What you have to permanently store, is just the information, that Zack is the new owner after 10 minutes, when the block is confirmed. For everyone else, you need just some kind of SPV proof, that somebody "owned" the coin, but you don't have to publicly reveal that information into the whole network (you can keep it private), and you also don't have to inform new nodes about it. In other words: you can compress the history, so the chain of signatures is still valid, and there is some visible proof, that it is correct, but also you don't have to publicly share all "in-between transactions", which occured in the meantime.

In general, you can inform the network about "in-between transactions" only when something is unconfirmed, and when you need that information, to properly resolve all double-spending attempts. But once something is confirmed in a block, then you have a strong cryptographic proof, which is covered by a lot of Proof of Work, that a given transaction happened, and you can easily reject all future double-spending attempts.

[ABCbits]

If yes, what factor should be considered when choosing new maximum size?

Verification time, also known as Initial Blockchain Download time. If you want to increase the size of the block, then you can never go beyond verification time. Because if you will, then new blocks will be produced at a rate, where maybe you could download all of them, but never verify all of them. And as long as you have to verify the whole chain, to be 100% sure, that your new blocks meet all consensus rules, you cannot do much with the maximum block size.

Which also means, that if you want to seriously consider any increase, then you have to improve Initial Blockchain Download first. If creating a new full node wouldn't require verifying over 500 GB of data, from the last 15 years, then you could think about increasing the size of the block.

Improvement for IBD is really limited though, unless you skip more verification or implement new feature such as UTXO commitment.

if the fees continue to rise such that it becomes difficult or impossible to use Bitcoin normally, then I think that both miners and society will agree to increase block size within a certain limits

There are ways beyond increasing block size, which could increase Transactions Per Second. One of them is transaction joining. For example: imagine that you have a lot of different coins, and for each of them, there is some public key, representing the owner. Imagine that the only information you need, is to know "who owns what", and you confirm it every 10 minutes. If you have a signature, which allows moving the coin from one public key to another, you can join a chain of signatures, and put only the last owner in the final block. Which means, that if you have a coin, which is owned by Alice, and then is passed into Bob -> Charlie -> Daniel -> ... -> Zack, forming a chain of unconfirmed transactions, then you don't have to record all of those transactions in the final block. What you have to permanently store, is just the information, that Zack is the new owner after 10 minutes, when the block is confirmed. For everyone else, you need just some kind of SPV proof, that somebody "owned" the coin, but you don't have to publicly reveal that information into the whole network (you can keep it private), and you also don't have to inform new nodes about it. In other words: you can compress the history, so the chain of signatures is still valid, and there is some visible proof, that it is correct, but also you don't have to publicly share all "in-between transactions", which occured in the meantime.

In general, you can inform the network about "in-between transactions" only when something is unconfirmed, and when you need that information, to properly resolve all double-spending attempts. But once something is confirmed in a block, then you have a strong cryptographic proof, which is covered by a lot of Proof of Work, that a given transaction happened, and you can easily reject all future double-spending attempts.

Mimblewimble (and other variant of non-interactive cut-through) exist, but i don't expect it'll be ever implemented on Bitcoin. Even though it can be done through soft fork (just like what LTC did), i wonder if community will accept it since it give government to restrict Bitcoin usage.

[garlonicon]

Mimblewimble (and other variant of non-interactive cut-through) exist, but i don't expect it'll be ever implemented on Bitcoin.

Why not? We currently have full-RBF, which means, that if some transaction is unconfirmed, then it can be replaced completely, without any restrictions. Transaction fee is the only indicator, if something should be replaced, or not. And I expect, that in the future, more people will make use of that, and we will see more and more replacements for unconfirmed transactions, so they will be batched on mempool level.

Because currently, imagine that you have a situation: Alice -> Bob -> Charlie. You have one transaction, which sends some coins from Alice to Bob, and another transaction, which passes them further from Bob into Charlie. If you assume that Alice is online, then there is no reason, to not write a replacement transaction Alice -> Charlie, while using the same fees, and get a higher feerate, because the size of that single transaction, will obviously be smaller, than the size of those two separate transactions, so miners will have no reason to stop that kind of replacement.

And of course, the next natural step, is to make it non-interactive. Because if we have full-RBF, then it means, that interactive version is already there, because full-RBF means "accept any replacement" (including double-spends).

Even though it can be done through soft fork (just like what LTC did)

I don't think Bitcoin will take the same path, as LTC did. It was the case in Segwit, but today, it is much more likely to get some other BIPs merged, for example something related to OP_CAT. And if you have OP_CAT, then it enables a lot of things, including the ability to accept any signature, and do something like OP_CHECKSIGFROMSTACK, but without any additional opcode (other than OP_CAT). And of course, note that doing all of those things, does not require making any "extension block", because you can just use the witness space, as Taproot did.

i wonder if community will accept it since it give government to restrict Bitcoin usage.

If that would be the case, then Bitcoin would be restricted, when it introduced Lightning Network. Because then, you also skip some transactions in the middle, and leave only two on-chain transactions: one to open some channel, and one to close it. Also, another case is Taproot, which allows you to have N people on a single UTXO, by forming N-of-N multisig, behind a single public key, and spending it with a single Schnorr signature.

Improvement for IBD is really limited though

It is not that limited, as you may think. For example: each coin starts from the coinbase transaction, and ends, when it is sent as fees. When it comes to the chain of signatures, it is broken each time, when you send something as a fee, because then the coin is no longer restricted by the Script, so it can be claimed by any miner. Which also means, that if you want to verify things, you don't have to check them deeper, than to the nearest coinbase transaction. Why? Because if the coinbase transaction has 100 confirmations, then it can be spent. And it is very unlikely to ever trigger a deeper chain reorganization, than 100 blocks (even the Value Overflow Incident reorged less than 100 blocks).

There are many bugs, where if something went wrong, then the historical state of the chain, was simply "grandfathered in", and new rules were applied on top of the later chain. One of those cases is for example duplicate coinbase transactions: nobody proposed throwing away the history to fix it (because it was deeply confirmed), and some coinbase transactions are just listed in the code as "exceptions" to some BIP, so they are ignored, while checking, if there are no duplicated transaction IDs.

unless you skip more verification

You don't have to skip it, if you don't want to. It can be fully optional, because if you replace Alice -> Bob -> Charlie transaction with just Alice -> Charlie, then it will probably contain Alice's signature. And inside that signature, you can put a proof, that there was Bob in-between, so some nodes can still access that history, and preserve it, if there would be any need to show someone, that "Bob owned some coins at this point in time". However, at the same time, it would no longer be strictly needed, if you want to synchronize the chain from scratch, because Alice's signature is correct from ECDSA point of view, and nothing else is needed to prove, that no coins were created out of thin air, and the system is honest.

[bitmover]

Mimblewimble (and other variant of non-interactive cut-through) exist, but i don't expect it'll be ever implemented on Bitcoin.

Why not? We currently have full-RBF, which means, that if some transaction is unconfirmed, then it can be replaced completely, without any restrictions. Transaction fee is the only indicator, if something should be replaced, or not. And I expect, that in the future, more people will make use of that, and we will see more and more replacements for unconfirmed transactions, so they will be batched on mempool level.

I would like to see those solutions being implemented in second layer.

I think ln is far too complicated and we should have multiple bitcoin second layers   , just like ethereum

[ABCbits]

Even though it can be done through soft fork (just like what LTC did)

I don't think Bitcoin will take the same path, as LTC did. It was the case in Segwit, but today, it is much more likely to get some other BIPs merged, for example something related to OP_CAT. And if you have OP_CAT, then it enables a lot of things, including the ability to accept any signature, and do something like OP_CHECKSIGFROMSTACK, but without any additional opcode (other than OP_CAT). And of course, note that doing all of those things, does not require making any "extension block", because you can just use the witness space, as Taproot did.

You're right, i didn't pay much detail on how LTC do that.

i wonder if community will accept it since it give government to restrict Bitcoin usage.

If that would be the case, then Bitcoin would be restricted, when it introduced Lightning Network. Because then, you also skip some transactions in the middle, and leave only two on-chain transactions: one to open some channel, and one to close it. Also, another case is Taproot, which allows you to have N people on a single UTXO, by forming N-of-N multisig, behind a single public key, and spending it with a single Schnorr signature.

You're partially right, but IMO LN is more complicated (e.g. routing and channel balance flow) and more suitable for micropayment, which attract less attention.

Mimblewimble (and other variant of non-interactive cut-through) exist, but i don't expect it'll be ever implemented on Bitcoin.

Why not? We currently have full-RBF, which means, that if some transaction is unconfirmed, then it can be replaced completely, without any restrictions. Transaction fee is the only indicator, if something should be replaced, or not. And I expect, that in the future, more people will make use of that, and we will see more and more replacements for unconfirmed transactions, so they will be batched on mempool level.

I would like to see those solutions being implemented in second layer.

I think ln is far too complicated and we should have multiple bitcoin second layers   , just like ethereum

For Mimblewimble, it's definitely better implemented on main network. After all, it allows higher TPS (transaction per second) since basically it combine many TX into one big TX.

[bitmover]

For Mimblewimble, it's definitely better implemented on main network. After all, it allows higher TPS (transaction per second) since basically it combine many TX into one big TX.

I don't know much about it. But is any big  project really using it?
Grin is basically  dead AFAIK  . I think those implementations of new ideas such be highly tested before being considered in bitcoin mainet.

Even ethereum pos took years to go to main net

[garlonicon]

Grin is basically  dead AFAIK  .

Well, many altcoins change a lot of things. I guess the current value of Grin does not come from choosing MimbleWimble, but rather from other design decisions, for example the basic block reward, and the total supply, which is completely different than in Bitcoin. Which means, that even if you introduce the same features, then still, there are other network rules, which can affect the price.

Another completely different choice is the mining algorithm, which is CuckatooC32, instead of SHA-256. Also, there were some different algorithms, used in previous versions, because people wanted to keep the coin ASIC-resistant. On the other hand, Bitcoin uses exactly the same algorithm, as it used in 2009. And being "ASIC-resistant" is not "free". If you make your hash function more complex, then you also make verification more complex as well.

Also, killing ASICs discourage a lot of miners, and then, the amount of work, which is needed to make a single block, is smaller, because of knocking out people with specialized hardware, so only more common mining devices like CPUs or GPUs stay in the network, and consequently, the network difficulty is much lower than it could be, and it is also reflected by the price of the altcoin.

[ABCbits]

For Mimblewimble, it's definitely better implemented on main network. After all, it allows higher TPS (transaction per second) since basically it combine many TX into one big TX.

I don't know much about it. But is any big  project really using it?
Grin is basically  dead AFAIK  . I think those implementations of new ideas such be highly tested before being considered in bitcoin mainet.

Even ethereum pos took years to go to main net

Probably only Litecoin, even though other coin like MWC and BEAM also implement it. But don't forget privacy coin generally isn't that popular either. And i agree it should tested first, just like SegWit and Taproot which took many years.