{"type":"rich","version":"1.0","author_name":"npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6r","author_url":"https://nostr.ae/npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6r","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-02-19\n📝 Original message:On Wed, Feb 19, 2014 at 9:28 PM, Michael Gronager \u003cgronager at mac.com\u003e wrote:\n\u003e I think that we could guarantee fewer incidents by making version 1 transactions unmalleable and then optionally introduce a version 3 that supported the malleability feature. That way most existing problematic implementations would be fixed and no doors were closed for people experimenting with other stuff - tx v 3 would probably then be called experimental transactions.\n\nJust to be clear: this change is not directly intended to avoid\n\"incidents\". It will take way too long to deploy this. Software should\ndeal with malleability. This is a longer-term solution intended to\nprovide non-malleability guarantees for clients that a) are upgraded\nto use them  b) willing to restrict their functionality. As there are\nseveral intended use cases for malleable transactions (the sighash\nflags pretty directly are a way to signify what malleabilities are\n*wanted*), this is not about outlawing malleability.\n\nWhile we could right now make all these rules non-standard, and\nschedule a soft fork in a year or so to make them illegal, it would\nmean removing potential functionality that can only be re-enabled\nthrough a hard fork. This is significantly harder, so we should think\nabout it very well in advance.\n\nAbout new transaction and block versions: this allows implementing and\nautomatically scheduling a softfork without waiting for wallets to\nupgrade. The non-DER signature change was discussed for over two\nyears, and implemented almost a year ago, and we still notice wallets\nthat don't support it. We can't expect every wallet to be instantly\nmodified (what about hardware wallets like the Trezor, for example?\nthey may not just be able to be upgraded). Nor is it necessary: if\nyour software only spends confirmed change, and tracks all debits\ncorrectly, there is no need.\n\n-- \nPieter"}