Hard vs soft fork: is there a third way to increase the Bitcoin block size?

[pondjohn]

There just might be!

Here's a discussion as to how, let me know your thoughts:

http://pondpolitics.com/2016/01/hard-vs-soft-fork-is-there-a-third-way-to-increase-the-bitcoin-block-size/

[1714612374]

1714612374

[1714612374]

1714612374

[1714612374]

1714612374

[manselr]

I don't think there's much to discuss about it to be honest. If you are talking about a strict block size, then yes a hard fork is required as far as I know. There can be workarounds like sigwit but that isn't actual increase.

[pondjohn]

Did you read the article? Here's an extract of the key part:

There is an entirely different debate about how much or even whether the block size limit needs raising, but here I will solely be doing my best to explain one of the ways a future block size increase could be achieved.

To begin with, I need to explain the difference between a hard and soft fork.

It relates to backwards compatibility. Imagine you and many others are playing an online game where you all roam around a virtual world together collecting flowers to score points. You’re all trying to achieve a high score.

One day, the game releases an update, and adds mushrooms to this world. Just like flowers, the mushrooms can also be collected to score points.

How this upgrade is implemented can be compared to a soft fork and a hard fork.

If the upgraded version of the software is not compatible with the old version, you have a hard fork. In this situation, anybody who updates their software will be in a new world, we’ll call it mushroom land, and anybody who has the old software will be in flower land. The people in mushroom land know they arrived there through an update. Back in flower land, people may wonder where all the other players disappeared to, but will continue to continue playing amongst themselves, not realising that everybody else is playing an updated version of the game, and that the high scores they’ve worked so hard to achieve will be lost when they eventually realise that they need to upgrade to mushroom land.

If the upgraded software has backwards compatibility with the old version, you have yourself a soft fork. In this situation, maybe people with the upgrade can see mushrooms, but to those who haven’t, the new mushrooms just look like more flowers. Crucially, people with the old software can still play with those who have upgraded, and even though the world looks a little different – ultimately everybody is still playing the same game.

So is there a third way?
Maybe there is. Let’s imagine that for technical reasons there is no way mushrooms can be introduced, even as flowers, without a software upgrade. Perhaps though, all players can participate in the same virtual world, except that those with the upgrade can also see mushrooms, while those without cannot. Crucially, people are not playing a completely different game, and when someone in flower land does upgrade they can take their score with them, and start collecting mushrooms without losing out.

How can this be achieved in Bitcoin?
Instead of just losing points, a worst case scenario for a Bitcoin hard fork would be people losing money. Whatever happens, there must always be a block produced with 1MB or fewer transactions, otherwise Bitcoin will hard fork as old software will not recognise the new block.

So how do we prevent anybody losing money? We create a mushroom block. This mushroom block can be larger than 1MB. The existing 1MB block remains in place as a legacy block. Transactions that make it into the legacy block can be viewed by everybody on the network, those in the mushroom block can only be seen by those who have upgraded.

Once any Bitcoin has made its way into a mushroom block, it can not be viewed or spent again by software that has not been upgraded. This isn’t quite a hard fork though as people on the old software will still be participating in the same network, they just won’t be able to see all the transactions that are actually taking place. If they try and spend Bitcoin that appears to be theirs on the old software, but actually has been spent on a mushroom block and belongs to someone else, all that will happen is that the miners will reject the transaction and they will not be able to spend it.

Ultimately, this is not ideal, and while it would no doubt create confusion, it would not create a complete hard fork and should not lead to anybody losing Bitcoin.

The only people who would actually need to upgrade for this to take place would be the miners. Technically speaking, they could have already done this and none of us would know. Since mining is far more centralised and dominated by a smaller group with a huge financial stakes, it is likely that such an upgrade could be achieved rapidly, once the software is ready of course. For everyone who hasn’t upgraded, Bitcoin would just become increasingly less useful until they did so.

[AgentofCoin]

Did you read the article? Here's an extract of the key part:

...
Ultimately, this is not ideal, and while it would no doubt create confusion, it would not create a complete hard fork and should not lead to anybody losing Bitcoin.
...

This doesn't make sense to me.

What it is saying is that, to get around a hard fork (and a soft fork), some miners will mine a new block type.
This new block is at 1MB, but can "expand" to bigger than 1MB, by allowing included txs to fall outside of that 1MB limit
and into the "mushroom" section of this new block. When you are in this section, you can not see, verify, or spend (technically).

That means when people use bitcoin, they won't know if their tx will be within the 1MB or the mushroom section.

This alone will cause too much damage to the market place, especially with merchants.
Bitcoin is based on a provable tx. Your now saying we won't be able to prove or see some txs.

[bitbollo]

Or tx go fast, or we need to expland block size...
Did you imagine a day when the mining will produce only block per day?
A lot of people can't use btc as they use today, for example in betting!
We have to wait hours and hours for a confirmation?!?  I see this as a problem
(I don't have a great btc culture&background).

[pondjohn]

This doesn't make sense to me.

What it is saying is that, to get around a hard fork (and a soft fork), some miners will mine a new block type.
This new block is at 1MB, but can "expand" to bigger than 1MB, by allowing included txs to fall outside of that 1MB limit
and into the "mushroom" section of this new block. When you are in this section, you can not see, verify, or spend (technically).

That means when people use bitcoin, they won't know if their tx will be within the 1MB or the mushroom section.

This alone will cause too much damage to the market place, especially with merchants.
Bitcoin is based on a provable tx. Your now saying we won't be able to prove or see some txs.

It would require that all miners have upgraded, and they all produce a new type of block that can contain more than 1MB of transactions.

People with updated software will be able to view/spend transactions in the new type of block, but people with the old software will find that some of their transactions fail.

Any damage this proposal would do, a hard fork would do too, but probably worse.

A hard fork could result in a merchant caught on the wrong side of the fork sending out an item they think the've received a payment for, when the transaction never existed on the winning newer fork.

In this mushroom blocks scenario, the merchant would just think they had never received the payment if it ended up in the mushroom block, but as soon as the software was upgraded, they would then be able to see that a payment had been received and dispatch the item - without the risk of losing Bitcoin.

Everyone would pretty quickly upgrade you would imagine once they were not receiving payments, and the people sending them told them they need to upgrade.

[AgentofCoin]

This doesn't make sense to me.

What it is saying is that, to get around a hard fork (and a soft fork), some miners will mine a new block type.
This new block is at 1MB, but can "expand" to bigger than 1MB, by allowing included txs to fall outside of that 1MB limit
and into the "mushroom" section of this new block. When you are in this section, you can not see, verify, or spend (technically).

That means when people use bitcoin, they won't know if their tx will be within the 1MB or the mushroom section.

This alone will cause too much damage to the market place, especially with merchants.
Bitcoin is based on a provable tx. Your now saying we won't be able to prove or see some txs.

It would require that all miners have upgraded, and they all produce a new type of block that can contain more than 1MB of transactions.

People with updated software will be able to view/spend transactions in the new type of block, but people with the old software will find that some of their transactions fail.

Any damage this proposal would do, a hard fork would do too, but probably worse.

A hard fork could result in a merchant caught on the wrong side of the fork sending out an item they think the've received a payment for, when the transaction never existed on the winning newer fork.

In this mushroom blocks scenario, the merchant would just think they had never received the payment if it ended up in the mushroom block, but as soon as the software was upgraded, they would then be able to see that a payment had been received and dispatch the item - without the risk of losing Bitcoin.

Everyone would pretty quickly upgrade you would imagine once they were not receiving payments, and the people sending them told them they need to upgrade.

Correct me if I'm wrong, but when all the miners "upgrade",
aren't they actually just using a new Bitcoin protocol, to get around the current protocol.

What is the difference between what you are proposing and what XTers and BigBlockers, are promoting?

[pondjohn]

It does share elements of a hard fork where the protocol is updated, yes.

I'm not speculating on block size increase, I'm just talking about hypothetically, if one were to occur, what is the best way to achieve it.

This method has the effect of degrading more gracefully for users on the old protocol, rather than suddenly leaving them on their own, vulnerable to double spend attacks.

[saturn643]

There absolutely is NOT a third way. Hard forks and soft forks encompass all upgrade possibilities, which happen to be a) upgrade is incompatible with previous clients (hard fork) or b) fork is backwards compatible with previous clients. Whichever way you decide to upgrade the network, the upgrade will fall into one of those two categories.

The idea you propose is a soft fork as it is still compatible with previous clients.

BTW, I think your explanation is a horrible and very very poor explanation of what ZoomT was actually trying to do. It has nothing to do with "mushroom blocks" and including transactions in the smaller blocks. In fact, the generalized soft fork idea proposed by him has no indication that any transactions except the coinbase would actually be stored in the small blocks. It essentially attacks those still running old software as they are unable to actually see new transactions and spend from them.

[Amph]

subchain for example does not utilize hard fork or soft fork, it is already there need consensus, so unless it is somehow already coded there

you need soft or hard fork, or you can add it via another project like blockstream for example

[manselr]

I don't think a dynamic blocksize is safe enough, I don't like this idea of an elastic amount of megabytes for the blocksize. A fixed limit is way safer, and this limit must be conservative, 1 or 2 seem like the correct one for now. We will see in the future.