Quote from: simonbtc on May 04, 2016, 07:52:24 PM

Quote from: gmaxwell on May 02, 2016, 01:03:14 AM

And when you've done that, tada you have segwit (specifically, you get the _exact_ construction that was used in elements alpha). But a version of it with a ugly construction that requires every Bitcoin speaking program to upgrade _simultaneously_, and invalidates any pre-created nlocktimed transactions which _will_ confiscate some amount of users' Bitcoins (because some parties have been signing payments then destroying private keys as a time-lock-safe mechanism).

Isn't this a user problem rather than a protocol issue? First, the protocol doesn't specify that a user must destroy their private key when creating nLockTimed transactions. Second, since there's no guarantee that any given transaction will ever be successfully mined, it doesn't seem prudent to pre-sign transactions which sit off-chain and only become valid for broadcast and potential mining in some distant future whilst also deleting the private key. If this destructive behaviour can be condoned, it beggars belief that zero conf transactions are considered unsafe.

While that is a user issue, it is not something that changing the protocol should mess with. If you change the protocol and you cause several users to suddenly have transactions that they just sent suddenly be invalid, you will anger many users and potentially cause them to stop using Bitcoin.

About destroying the keys, there are some companies that provide multisig addresses and a pre-signed timelocked transaction to allow users to withdraw their balance should the service suddenly go down. If the service went down and this change happened, those users would no longer be able to access their coins.