Quote from: knightdk on March 19, 2016, 11:20:40 AM

Quote from: molecular on March 19, 2016, 08:09:37 AM

Quote from: TierNolan on March 18, 2016, 01:16:54 PM

Quote from: kn_b_y on March 18, 2016, 12:28:11 PM

One example gmaxwell gives: all presigned nlocktime transactions would be broken. For users keeping these in storage they may well represent a lot of security. Gone... the moment a new version of the software no longer sees the transaction as being valid.

You could have a rule that you can refer to inputs using either txid or normalized-txid. That maintains backwards compatibility. The problem is that you need twice the lookup table size. You need to store both the txid to transaction lookup and the n-txid to transaction lookup.

The rule could be changed so that transactions starting at version 2 using n-txid and version 1 transactions use txid. This means that each transaction only needs 1 lookup entry depending on its version number. If transaction 1 transactions cannot spend outputs from transaction 2 transactions, then the network will eventually update over time. It is still a hard-fork though.

Is that applicable / workable?

The first is possible but it is not optimal because it requires twice the lookup table size.

The second is also possible but the issue is the hard fork. The problem is that hard forks shouldn't be done often and for small things like this. It would be better if it was packaged with other stuff that is desired that also requires a hard fork. If also has less functionality than segwit.

Thanks for the info and those clarifications.

I understand you take issue with hardforking in general and I don't want to downplay the inherent risks.

I'm not suggesting to do a hard-fork just for this. I'm investigating the feasability of assembling a compromise package of changes. As you said:

Quote from: knightdk on March 19, 2016, 11:20:40 AM

It would be better if it was packaged with other stuff that is desired that also requires a hard fork.

Mainly here I'm reacting to Maxwell saying txid change couldn't be deployed as a hardfork at all, because that quote very publicly being used on reddit to defend "segwit as a softfork".

Quote from: gmaxwell on March 16, 2016, 10:22:57 PM

Would it change how transaction IDs were computed, like elements alpha did? Doing so is conceptually simpler and might save 20 lines of code in the implementation... But it's undeployable: even as a hardfork-- it would break all software, web wallets, thin wallets, lite wallets, hardware wallets, block explorers-- it would break them completely, along with all presigned nlocktime transactions, all transactions in flight.

So that's basically FUD?