Re: [bitcoin-dev] Increasing the blocksize as a (generalized) softfork.

[Tier Nolan <tier.nolan@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1762 bytes --]

This is essentially the "nuclear option".  You are destroying the current
chain (converting it to a chain of coinbases) and using the same POW to
start the new chain.  You are also giving everyone credit in the new chain
equal to their credit in the old chain.

It would be better if the current chain wasn't destroyed.

This could be achieved by adding the hash of an extended block into the
coinbase but not requiring the coinbase to be the only transaction.

The new block is the legacy block plus the associated extended block.

Users would be allowed to move money to the extended block by spending it
to a specific output template.

<public key hash> OP_1 OP_TO_EXTENDED OP_TRUE

OP_1 is the extended block index and initially, only one level is available.

This would work like P2SH.  Users could spend the money on the extended
block chain exactly as they could on the main chain.

Money can be brought back the same way.

<public key hash> <txid1> <txid2> ... <txid-n> <N> OP_0 OP_UNLOCK OP_TRUE

The txids are for transactions that have been locked in root chain.  The
transaction is only valid if they are all fully funded.  The fee for the
transaction would be fee - (cost to fund unlocked txids).  A negative fee
tx would be invalid.

This has the advantage that it keeps the main chain operating.  People can
still send money with their un-upgraded clients.  There is also an
incentive to move funds to the extended block(s).  The new extended blocks
are more complex, but potentially have lower fees.  Nobody is forced to
change.  If the large blocks aren't needed, nobody will both to use them.

The rule could be

Now:
0) 1 MB

After change over
0) 1 MB
1) 2 MB

After 2 years
0) 1 MB
1) 2 MB
2) 4MB

After 4 years
0) 1 MB
1) 2 MB
2) 4MB
3) 8MB

[-- Attachment #2: Type: text/html, Size: 2307 bytes --]