Increasing the blocksize as a (generalized) softfork.

[ZoomT]

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:

Code:

    NewBlock := BlockHeader ++ NumTx ++ Ver1Txs ++ Ver2Txs
    f(NewBlock) = BlockHeader ++ |Ver1Txs| ++ Ver1Txs

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.

[1714695947]

1714695947

[1714695947]

1714695947

[1714695947]

1714695947

[1714695947]

1714695947

[1714695947]

1714695947

[ZoomT]

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

[kanzure]

generalized soft-forks:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012073.html

bip102 forced soft-fork:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012153.html

auxiliary blocks and evil soft-forks or forced soft-forks:
https://bitcointalk.org/index.php?topic=283746.0
https://bitcointalk.org/index.php?topic=874313.0

soft-fork block size increase using extension blocks:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008356.html

extension blocks were also discussed in this interview:
http://diyhpl.us/wiki/transcripts/bitcoin-sidechains-unchained-epicenter-adam3us-gmaxwell/
.... which includes something very similar to the idea of a soft-hard fork (something I was informed about on 2015-06-13 ..... not sure if I should mention this?)

some discussion from today re: origin of the term evil fork, evil soft-fork, forced soft-fork:
https://www.reddit.com/r/Bitcoin/comments/3yrsxt/bitcoindev_an_implementation_of_bip102_as_a/cyg2g7q

some much older discussion about extension blocks and sidechains:
http://gnusha.org/bitcoin-wizards/2015-01-01.log

some discussion about "generalized soft-forks" and extension blocks and evil soft-forks:
http://gnusha.org/bitcoin-wizards/2015-12-20.log

segwit soft-fork makes use of a similar idea:
http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/segregated-witness-and-its-impact-on-scalability/

discussion about evil forks and evil soft-forks and extension blocks:
http://gnusha.org/bitcoin-wizards/2015-12-30.log

fork types:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012172.html

these links are also mentioned here:
https://www.reddit.com/r/Bitcoin/comments/3yrsxt/bitcoindev_an_implementation_of_bip102_as_a/cyg7mdr

and also mentioned here:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012173.html

[JorgeStolfi]

This seems to be the same idea, but using an "extension record" approach instead of a separate blokchain:

Original comment by /u/seweso on reddit

My understanding of the proposal

Comparison to the hard fork approach

[ZephramC]

Slightly off-topic...
Isn't the Note concerning 4 July 2015 problem a bit obsolete?

Note: this situation has not been fully resolved, and it does not appear that it will be fully resolved anytime soon.
(Last update: 2015-07-15)

[LiteCoinGuy]

"of course" you dont need a hard fork. "of course" everybody wants an increase.
but it is not blockstream approved. end. 

[_smudger_]

This is a great proposal. This gets over the problem that even if consensus (say 75%) is reached how do we ensure transactions are not lost before everyone (100%) has upgraded or risk being on a losing chain forever.

Under this proposal we no longer need as much as 75%, 55% would probably do and the rest can safely upgrade with all transactions ending up on the winning chain because, by the time we reach 55%, we will know which chain will win.  

[seweso]

I propose the old chain actually keeps a record of legacy transactions, and that the new chain effectively becomes a sidechain (of sorts).

Do two-way peg using spend-all coins (like SW) in the original chain. So new transactions can actually send coins to legacy addresses.

I assume SW is not yet implemented, so that's why I simply copy some SW tricks.

1. A transaction is send to a spend-all address (legacy chain), segregated witness data is added to the segregated block (like SW).
1. Transactions to/from segregated addresses only go into the segregated chain
1. When creating a transactions to legacy addresses a transaction is created from any spend-all transaction (legacy chain) and coins are destroyed (on the segregated chain)

Miners would then simply check whether all spend-all transactions in the legacy actually came from "destroyed" coins in the new chain.

[ZoomT]

I propose the old chain actually keeps a record of legacy transactions, and that the new chain effectively becomes a sidechain (of sorts).

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.

[indstove]

I want to say softfork is best rather than hardfork, as the bitcoin node base has been huge and expanding rapidly. It will help quick updation in no time.

[pondjohn]

Hi ZoomT, I attempted to provide a non-technical explanation of the principal for how a generalised softfork could be achieved, is this a fair representation of your basic principle?

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

[ZoomT]

Hi ZoomT, I attempted to provide a non-technical explanation of the principal for how a generalised softfork could be achieved, is this a fair representation of your basic principle?

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.