I just realize that the 1MB block size limit could be increased with a softfork. I call it auxiliary block:

1. An auxiliary block is created for each main block. Auxiliary block looks like a traditional block without the header.

2. OP_NOP1 is redefined as OP_AUX

3. Initially, auxiliary blocks are empty, until someone sends X bitcoin to a scriptPubKey of this format: <serialized script x> OP_AUX. This will create a coinbase-like transaction in the auxiliary block, with X bitcoin sending to <deserialized script x>. The Merkle Root of the auxiliary block will be included in the coinbase of the main block. All upgraded nodes will check whether the bitcoins are correctly transferred from the main chain to the aux chain

4. People can transfer aux chain bitcoins like in the main chain. Miners can also collect fee in the aux chain using the same mechanism as the main chain. The only difference is there is no generation bonus in aux chain. New aux coins are generated if and only if someone send bitcoins to <serialized script> OP_AUX in the main chain

5. When someone want to transfer Y aux coins back to the main chain, he will send Y aux coins to a scriptPubKey of this format: <serialized script y> OP_AUX OP_RETURN. Seeing this, the miner will randomly choose some OP_AUX UTXO in the main chain, with value exactly equals to Y bitcoins, and pass them to <deserialized script y> in the main chain.

Backward compatibility:

1. Since old nodes will not see the aux block, the aux block could be indefinitely big

2. The OP_AUX outputs look like anyone-can-redeem so old nodes won't complaint.

3. If some try to steal these OP_AUX outputs without following the new rules, however, they will be rejected by the majority of miners.

4. Old nodes can still mine. As long as they are not trying to include or redeem OP_AUX transactions, their blocks are still valid.

(More extremely, we may disallow people transferring aux coin back to the main chain by requesting them to send bitcoin to <serialized script x> OP_AUX OP_RETURN on the main chain. This will provide better backward compatibility since such outputs are not redeemable in both new and old nodes, and old miners would see these as non-standard and won't mine them)

What's really interesting about this approach is how users and miners are both required to buy into a larger blocksize, which means that adopting a larger blocksize requires the economic majority to convincingly show that they do in fact wish it to happen. Note how SPV users are required to accept the change as well if they want to accept aux-block coins as payment.

If there is no aux transaction, there will be no aux-block, even from a upgraded miner. So basically aux-blocks do not form a chain. They are the extension of the main blocks, indicated by the Aux-Merkle-Root in the main-coinbase.

For backward compatibility, aux-block will not be sent to old nodes. A new command like getauxblock will be used among new nodes.

What's really interesting about this approach is how users and miners are both required to buy into a larger blocksize, which means that adopting a larger blocksize requires the economic majority to convincingly show that they do in fact wish it to happen. Note how SPV users are required to accept the change as well if they want to accept aux-block coins as payment.

And since this is a soft-fork, it avoids a lot of political considerations. Anyone with 51% hashing power could implement this (if they can code)

Just a minor note: just like v2 block, the aux-coinbase must include the height of the corresponding main block to avoid crash of tx hash.

With aux-block, some other hardforks could also become softforks. For example, the calculation of tx hash in aux-block may exclude scriptSig, so transactions are identified purely by their inputs and outputs.

2. The OP_AUX outputs look like anyone-can-redeem so old nodes won't complaint.

So old nodes wouldn't complain if a miner would transfer all coins from the aux-blocks to his own address.The only incentive for miners to not do this, is that they know that these blocks would be considered invalid by more than 50% of hashing power if most miners have upgraded.

But, wouldn't the system be incompatible for miners with old software (without the upgrade).Some attacker (does not need to be a miner, just a regular client) might create transactions to redeem the coins in the aux-block. These transactions would seem valid for old miners. These miners with old versions would accept these transactions and therefore their blocks would be invalid for upgraded miners.

Once a transaction is in the aux block all of its children must forevermore be in the aux block.

This was also how I thought we could implement a new transaction syntax (one that makes the scriptsigs prunable) and switch to using hash-sum trees to make the coinbase value provable: move all txn into a separate tree eventually, and eventually require that the only txn in a block be the coinbase.

The downside is that until the transition is complete you have degraded fungibility with two kinds of Bitcoins.

So old nodes wouldn't complain if a miner would transfer all coins from the aux-blocks to his own address.

If an attacker did that, then he would fork the chain. "Soft-fork" is actually relative. It means that there are 2 sets of rules, but the majority of the hashing power supports the more restrictive rules.

This means that blocks that are banned by the restrictive rules are orphaned by a majority of the hashing power.

A soft fork switches to an actual fork (2 incompatible chains), if the majority of the hashing power deserts it.

Once a transaction is in the aux block all of its children must forevermore be in the aux block.

This was also how I thought we could implement a new transaction syntax (one that makes the scriptsigs prunable) and switch to using hash-sum trees to make the coinbase value provable: move all txn into a separate tree eventually, and eventually require that the only txn in a block be the coinbase.

The downside is that until the transition is complete you have degraded fungibility with two kinds of Bitcoins.

With this approach, we could change pretty much everything in the protocol with soft-fork. Just some examples:

The way to calculate tx hash

Coin divisibility

New fields in block header and transaction

Native color coin support

Shorten block time interval

Ultimately, we could trim the original Satoshi protocol to absolutely minimal (probably except the few involving block headers like double SHA256 PoW and Merkle Tree), and implement a completely new set of rules

For the fungibility problem, a very aggressive solution is to create a genesis-aux-block with all UTXO in the main chain. New miners will collect their reward in the aux-chain only, and they will reject any main chain tx except the dummy coinbase tx with zero value. So all old nodes are broken immediately, but it's still a softfork because the PoW is still valid for them. I call this the ultimate-51%-attack.

Unfortunately, this also means that 51% miners could violate the Satoshi philosophy. They could print as many aux coins as they want, steal ancient aux UTXO, etc. Minority users need to hardfork if they don't like these rules.

So old nodes wouldn't complain if a miner would transfer all coins from the aux-blocks to his own address.

If an attacker did that, then he would fork the chain. "Soft-fork" is actually relative. It means that there are 2 sets of rules, but the majority of the hashing power supports the more restrictive rules.

This means that blocks that are banned by the restrictive rules are orphaned by a majority of the hashing power.

A soft fork switches to an actual fork (2 incompatible chains), if the majority of the hashing power deserts it.

If a soft fork is implemented correctly, there will be no fork at all. (see the v1 to v2 block transition)

Unfortunately, this also means that 51% miners could violate the Satoshi philosophy. They could print as many aux coins as they want, steal ancient aux UTXO, etc. Minority users need to hardfork if they don't like these rules.

You can see someone attempting this right now with "mastercoin" which is apparently supposed to be an alt-coin which forces Bitcoin nodes to store its data by stuffing them in perpetually non-redeemable utxo... so it even goes a step beyond undermining the rules with an alternative system, it moots pruning in Bitcoin and would eventually— if successful— make it much harder to run a validating node.

If a soft fork is implemented correctly, there will be no fork at all. (see the v1 to v2 block transition)

Right, the question was what happens if 51% violate the rules of the soft fork, after it has been accepted.

The miners of 750 of the last 1000 blocks add "/AUXBL/" to their coinbase

This proves that miners support the (soft) fork

Once that happens, the change is "locked-in". New blocks that violate the new rules are simply rejected and new clients have the rule built in.

New clients and old client all track the same main chain. Miners still using the old rules are orphaned almost immediately.

An attacker arrives (with 51%) and violates the new rules. This converts a (correctly implemented) soft fork into an actual fork. All old clients follow the attacker and all new clients follow the updated rules.

The attack has split the network.

If the soft fork rule allowed reversion, then after 1000 blocks, even the new clients will follow his chain, since less than 750 of the last 1000 blocks will have the coinbase message.

The thing I don't like is that all of the workarounds to create soft-forks make bitcoin unnecessarily more complicated. A hard fork set for some date in the future allowing people time to upgrade would be much more simple.

The thing I don't like is that all of the workarounds to create soft-forks make bitcoin unnecessarily more complicated. A hard fork set for some date in the future allowing people time to upgrade would be much more simple.

The complicated part should be transparent to users. Eventually, all tx will happen in the aux block, leaving only a dummy coinbase tx in the main block (which works as extended block header). The risk of hardfork is too high and I believe it should be used only in absolutely necessary cases like:

Bug fix like BIP50

Timestamp overflow in year 2106

SHA256 is completely compromised

I believe these are the ONLY scenarios that a hardfork is unavoidable. Please point out other scenario if anyone finds one.