Quote from: jackjack on July 18, 2013, 09:44:27 PM

Quote from: twobits on July 18, 2013, 09:11:07 PM

Block 250 has to return a 0 subsidy. Superblocks can not kick in to some future block number that gives people time to update the client.

Edit: or maybe 250 has to be a 0 or a superblock chance, have to find the original code to remember for sure.

Block 250 is not supposed to be 0, I quoted r3wt stating this a few pages ago.
And yeah, I wasn't sure if anybody was really using the client so I just followed what Vlad asked. Also block 250 would create a hard fork anyway as the current code makes it 0 and my fix makes it 49.

It doesn't really matter here (given this coin is dead anyways) but as an academical point of view if a hard fork is necessary it should be a future hard fork.

It doesn't matter what block 250 "should have been", block 250 on the current longest chain has a value of 0 coins. If you change that you will cause a catastrophic re-org back in time to block 250. This is an absolute worst case scenario. Once again this is academic because this coin is dead anyways but a good learning lesson.

Once a mistake is made and the chain has moved beyond that the "fix" is to keep it the same. As an example Satoshi had intended the genesis block to be spendable but a bug in the code prevents it from being spent. The "fix" is to keep that block unspendable forever. Trying to correct it to what "should have been" would cause a irrecoverable hard fork if/when someone tried to spend the genesis block.

The mistakes were:
a) block 250 is 0 coins
b) super blocks are not possible through the current block due to a bug.
c) no subsidy decline just drop to 0 in 7 years (we will ignore this one because it isn't pressing although it does ensure this coin is DOA).

The fix is:
a) keep block 250 as 0 coins.
b) keep no superblocks through some future block (estimate the time necessary to get super majority of nodes to upgrade)
c) implement superblock fix on blocks AFTER the block in "b"

This will keep the current longest chain valid and allow migration at some future block height to enable the superblocks. Otherwise you introduce the abiltity to double spend. Some users have already received coins in blocks 251+. Those users have sold them on exchanges (in theory). Changing the "correct" value for block 250 would cause all nodes running the corrected code to see the entire existing chain from block 250 onward as invalid. The coins held by exchanges would disapear in the reorg.

Obviously any hard fork is bad and testing and proper deployment should be done to minimize the need for hard forks however if you must use a hard fork it should only be done in a forward fashion. At block XXXX in the future old nodes and new nodes will fork not at block yyyy which is way in the past we just erase the majority of the existing change.