Quote from: knightdk on December 20, 2015, 04:22:26 PM

I see a few problems with those proposal

1) You are proposing to fork the blockchain without consensus. This in itself is a problem, we don't want to fork without consensus (even with a soft fork) because there is still the possibility of the old chain surviving, and that can lead to some major problems.

Actually, using this proposal, it looks like the only way the old chain could survive is if the users that don't want the new chain create a hard fork to reject the blocks created by those that do want the new chain.

Quote from: knightdk on December 20, 2015, 04:22:26 PM

2) Your generalized soft fork idea breaks one of the basic principles of Bitcoin, storing all of the transaction history in the blockchain. It is not possible to know what the transaction data is if you use your idea to transform blocks under new rules to blocks under old rules. It isn't backwards compatible so it isn't a soft fork. If I ran a client with the old rules, then I would not be able to know what the transactions were in that block without having to download the fork. That is completely pointless.

If I'm understanding this proposal correctly, it could be described as a hard fork with a simultaneous majority hash power attack on the old fork.

The OP has indicated a method by which the hash power that hashes the blocks on the new format side of the hard fork can simultaneously hash empty blocks on the old format side.

That way, once the hashing participants on the new format side have enough hash power, the old format side will no longer be able to confirm any transactions ever again. They will be forced to either hard fork to keep their old format, or they will have to join the new format.