If they simply changed the blocksize limit, this would be a hardfork, so the network will split into two incompatible versions as soon as a >1MB block is mined.

However, a firm softfork (sample code) achieves the same thing (2MB limit rise) except the network cannot split.  The code is a bit more complicated however.

Thanks for writing this.  In terms of analogies, I was thinking something like this:

Bitcoin = flower picking game
Example Softfork = everyone must pick only yellow flowers
Example Hardfork = everyone must pick mushrooms instead of flowers
Example "Generalized" Softfork = everyone must pick flowering mushrooms

The example softfork does not violate the original rules of the game, i.e. everyone is still picking flowers, albeit yellow flowers.

The example hardfork changes the rules to a new game (mushroom picking).

The example generalized softfork effectively achieves the same thing as a hardfork (upgrading everyone to mushroom picking) but as a softfork (technically everyone is still picking flowers as well).

I do not think there is such thing as a flowering mushroom however.

As mentioned on reddit, this idea seems very similar to "extension/auxiliary blocks", although maybe there are some differences (?).

There is nothing wrong with this kind of idea other than it adds more complexity for the sake of better backwards compatibility (i.e. it's a trade-off).  Personally I prefer the simpler solution as backwards compatibility is only a short-term problem, whereas any complexity it introduces can remain forever.

An implementation of BIP102 as a softfork using this idea:

https://github.com/ZoomT/bitcoin/tree/2015_2mb_blocksize
https://github.com/jgarzik/bitcoin/compare/2015_2mb_blocksize...ZoomT:2015_2mb_blocksize?diff=split&name=2015_2mb_blocksize

A miner majority (i.e. like a softfork) can force changes to the Bitcoin protocol using the method described here: https://bitcointalk.org/index.php?topic=1296628.0

The above proposal was for blocksize limit increases (mildly controversial), but the same idea could in principle be used for other changes that would otherwise require a hardfork.

I was also thinking it may be possible to redesign the idea such that the old chain is not empty.  This could be achieved by introducing a new transaction version number, e.g. version=2, and all version 2 transactions cannot appear in the legacy transformed f(B) blocks.  However, old version=1 transactions can appear subject to the 1MB blocksize limit.  However, once a coin has been used in a version=2 transaction, it and all child transactions can never again appear in the legacy block.

So:
And the MerkleRoot in the header corresponds to the transformed block.

This is more like extension/aux blocks, except:

* There is no need to explicitly move coins to the extension.  Instead they are moved "automatically" when an new client issues a version=2 transaction.
* Coins can never be moved back out from the extension.  There is no need to do this anyway, since there is no aim to support old clients indefinitely (remember this is a proposed alternative to a hardfork, which is immediately incompatible with old clients anyway).

This means old clients can still send coins, but may not be able to see received coins unless they upgrade.

For the 4th July fork the old chain was nothing but empty blocks (a bit like the above proposal).  So they cannot lose money unless they were accepting zero-conf txs.

I think your proposal sounds similar to "aux" blocks from above.

There is nothing wrong with these kinds of proposals except that they are arguably more complex for users.

My proposal is more like a simple blocksize hardfork, except can be deployed like a softfork.


Quoted.

A softfork is the same as a 51% attack against the old rules.  The generalized softfork is no different.  I think DannyHamilton understands this.

This is why I called it a "generalized" softfork, since it has properties of softforks but has the power of a hardfork (in this case).  It is sort of an "in-between" kind of fork.


I do not disagree but the same it true for all softforks (e.g. OP_CLOCKTIMEVERIFY).


Since this is a (generalized) softfork, there is a very strong incentive for miners to upgrade to the new rules (orphaned blocks).  So this should not happen provided the majority hash power are on board when the fork occurs.

However, if it *did* happen, then this is a disaster no matter how the fork is designed.  Either the old (longer) chain is rejected as invalid, or there is a very large reorg undoing many multi-confirmation transactions.

Technically this can be done via a standard softfork.

The same is true for any softfork.  For example, if some portion of the hashpower were passionately against the OP_CLOCKTIMEVERIFY fork, they could create a competing softfork that makes any block including a OP_CLOCKTIMEVERIFY transaction invalid.  If this occurred, then Bitcoin will split into two competing cryptocurrencies (both softforks of the original chain).


Yes, in the same way a standard softfork uses the majority hash power to attack any chain under the old rules.

No, a hardfork requires everyone to upgrade to a new client.  After a hardfork old clients will outright reject the new chain.

If that does not happen, and if a significant portion of the hashpower refuses to upgrade, then Bitcoin will split into two completing cryptocurrenies that can co-exist forever.  This is the worst-case scenario.

I have seen a similar proposal labeled as "extended blocks".  It is also possible to view these ideas as a "generalized softforks" if one so desires.

The main difference is that there are no different types of blocks.  In fact, the new block format is essentially the same as the old block format sans for a new blocksize limit.

A generalized softfork has the same minimum requirements of a standard softfork, i.e. >50% of mining hashpower.  In practice it would wiser to shoot for something beyond the bare minimum, such as the standard 75% or 95% of hash power as with other forks.  The point is that this proposal is no different than other softforks in terms of requirements.


This proposal is an alternative to hardforks which completely replace the blockchain with a new version under different rules.  My proposal does exactly the same thing, but does so essentially as a softfork.  The new chain keeps all the the transaction history on the chain under the new rules.

Introduction

It is generally assumed that increasing the blocksize limit requires a
hardfork.  Instead we show that a increasing the limit can be achieved using a
"generalized" softfork.  Like standard softforks, generalized softforks need a
mere miner majority (>50% hashpower) rather than global consensus.

Standard Softforks

After a softfork two potential chains exist:

* The new chain B3,B4,B5,... valid under the new rules and old rules.
* The old chain B3',B4',B5',... valid under the old rules only.

E.g.


Assuming that >50% of the hashpower follow the new rules, the old chain is
doomed to be orphaned:


Hardforks may result in two chains that can co-exist indefinitely:


Generalized Softforks

A *generalized* softfork introduces a transform function f(B)=B' that maps a
block B valid under the new rules to a block B' valid under the old rules.

After a generalized softfork three chains may exist:

* The new chain B3,B4,B5,... valid under the new rules only.
* The mapped chain f(B3),f(B4),f(B5),... valid under the old rules.
* The old chain B3',B4',B5',... valid under the old rules only.

E.g.


This is "generalized" softfork since defining f(B)=B (identity function)
reduces to the standard softfork case above.

As with standard softforks, if the majority of the hashpower follow the new
rules then the old chain B3',B4',B5',... is doomed to be orphaned:


Example:

Segregated Witness can be thought of as an example of a generalized softfork.
Here the new block format consists of the combined old block and witness data.
The function f() simply strips the witness data to reveal a valid block under
the old rules:


An Arbitrary Block-size Increase Via a Generalized Softfork

Segregated Witness only allows for a modest effective blocksize increase
(although there can be other motivations for SW, but that is off-topic).

Instead we engineer a generalized softfork that allows an arbitrarily increase
of the blocksize limit.  The proposal consists of two parts: (a) new rules for
valid blocks, and (b) a transformation function f().

The new block rules are very similar to the old block rules but with some
small changes.  In summary the changes are:

* The MAX_BLOCK_SIZE limit is raised to some new limit
  (e.g. 8Mb, BIP101, 2-4-8, BIP202, etc., or some other limit)
* The MerkleRoot field in the header has been re-interpreted.
* The CoinBaseTx must obey some additional new rules.

As with old blocks, a block under the new rules consists of a block header
followed by a vector of transactions [CoinBaseTx, Tx1, .., Txn], i.e.


The block header format is the same as under the old rules defined as follows:


Under the old rules MerkleRoot is the Merkle root of the hashes of all
transactions included in the block, i.e.


Under the new rules we instead define:


That is, under the new rules, MerkleRoot is the Merkle root of a singleton
vector containing the CoinBaseTx hash only.

In order to preserve the security properties of Bitcoin we additionally
require that the CoinBaseTx somehow encodes the Merkle root of the remaining
transactions [Tx1, .., Txn].  For example, this could be achieved by requiring
a mandatory OP_RETURN output that encodes this information, e.g.


Alternatively the Merkle root could be encoded in the coinbase itself.  This
ensures that new transactions cannot be added/deleted from the block without
altering the MerkleRoot field in the header.

Aside from these changes and the increased MAX_BLOCK_SIZE, the new block must
obey all the rules of the old block format, e.g. valid PoW, have valid block
reward, contain valid transactions, etc., etc.

In order to be a generalized softfork we also need to define a mapping f()
from valid new blocks to valid blocks under the old rules.  We can define this
as follows:


That is, function f() simply truncates the block so that it contains the
coinbase transaction only.  After truncation, the MerkleRoot field of the
block header is valid under the old rules.

The proposed new rules combined with the transformation f() comprise a
generalized softfork.  After the fork a new chain B3,B4,B5,... will be
generated under the new rules defined above, including an increased blocksize
limit.  This new chain can be mapped to a valid chain f(B3),f(B4),f(B5),...
under the old rules.  Assuming that >50% of the hashpower has adopted the new
rules, the mapped chain will orphan any competing chain under the old rules,
just like a standard softfork.

An interesting consequence of this design is that, since all mapped blocks are
empty, old clients will never see transactions confirming.  This is be a
strong incentive for users to update their clients.

Conclusion

Conventional wisdoms suggests that increasing the blocksize limit requires a
hardfork.  We show that it can instead be achieved using a generalized
softfork.  Like with a standard softfork, a generalized softfork merely
requires a majority (>50%) of hash power rather than global consensus.
Experience has shown that the former is significantly easier to achieve.

Future Work:

Investigate other kinds of hardforks that can instead be implemented as
generalized softforks, and the security implications of such...

7943a2934d0be2f96589fdef2b2e00a2a7d8c3b782546bb37625d1669accb9b1
72f018588572ca2786168cb531d10e79b81b86d3fada92298225a0f950eed3a5