Quote from: TierNolan on March 19, 2016, 07:33:53 PM

Quote from: knightdk on March 19, 2016, 12:47:03 PM

Additionally, on further thought, it will still require twice the lookup tables. There needs to be one for the transactions that version 1 txs can spend from and one for the version 2 txs. Version 2 txs still need to be able to reference the txid of a version 1 tx to spend from it or that ntxid for the version 1 tx also needs to be stored somewhere so it will increase the lookup table sizes.

I meant if you want to refer to a version 2 transaction, you use the n-txid. The reason that this is ok is that legacy/timelocked transactions are automatically version 1, so it doesn't make locked transactions suddenly unspendable.

Version 1 transactions would only refer to version 1 inputs (so no change)
Version 2 transactions would use txid when referring to version 1 inputs and n-txid when referring to version 2 inputs.

The nice feature of this is that n-txid don't need to recomputed back to the genesis block.

It is a hard-fork though. I should have been clearer. Given that SW can achieve the same with a soft fork, I think SW wins here.

Maybe SW should have happened in stages. The first stage could have been purely adding SW and no other changes (other than script versioning). Later script versions could add the new hashing rules.

In fairness, they have been trying to keep feature creep to a minimum.

With regards to the O(N²) hashing operation. The transactions could simply have been limited to 1MB. This would have meant no changes at all. The O(N²) performance assumes that the block contains a single transaction.

If N squared performance assumes a single giant transaction, why not a rule to limit the size of a transaction?