{"type":"rich","version":"1.0","author_name":"npub1nc78dlt7hp3v5dl32qu3m678h2j0ss374glcjnz8df75xcx7ngpq4gw452","author_url":"https://nostr.ae/npub1nc78dlt7hp3v5dl32qu3m678h2j0ss374glcjnz8df75xcx7ngpq4gw452","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-02-20\n📝 Original message:As I see the BIP it is basically stressing that ver 1 transactions are malleable.\n\nIt then addresses the need for unmalleable transactions for e.g. spending unconfirmed outputs in a deterministic way (i.e. no 3rd party can sabotage) - this transaction type is defined as ver 3.\n\nA lot of clients today spend unconfirmed outputs (even bitcoin-qt) and as such make an implicit assumption that this is kind of safe, which it is not - it can be intervened and sabotaged through tx malleability.\n\nWhat I suggested was to ensure that a subclass of version 1 transactions become unmalleable - namely those with sighash=all. Note that only the sender can modify the sighash as it is part of the hash signed. So instead of defining a version 3, we could constrain version 1 txes with sighash=all to have a unmalleable hash. If you e.g. would like to still have a sighash=all type of transaction with malleable features you can simply use that sighash=all today is checked for using sighash\u00260x1f=sighash_all, so just OR'ing with 0x20 or 0x40 will get you the 'old' feature.\n\nI do however buy the argument of Peter and Gregory that there might exist unpublished transactions out there that does not even conform to the DER rules etc, and as such we cannot forbid them from being mined, nor can we timestamp them and include 'only the old ones'. Hence we cannot change the consensus rule for version 1 transactions - and only changing the relay rules will not provide a certain guarantee.\n\nSo, I think the two line argument for the BIP is as follows:\n1. We cannot change the consensus rules for version 1 transactions as that might invalidate unpublished non-standard transactions (= voiding peoples money, which is a line we don't want to cross)\n2. The prime usecase for unmalleable transactions is being able to spend unconfirmed outputs - this is done today by almost all clients, but it is really broken. Hence a need for a fix asap.\n\nI am all in favor for the BIP, but I expect the realistic timeline for enforced version 3 transactions is roughly one year, which is better than two, but it would have been nice to get it faster...\n\n/M\n\n\nOn Feb 19, 2014, at 10:11 PM, Pieter Wuille \u003cpieter.wuille at gmail.com\u003e wrote:\n\n\u003e On Wed, Feb 19, 2014 at 9:28 PM, Michael Gronager \u003cgronager at mac.com\u003e wrote:\n\u003e\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\u003e \n\u003e Just to be clear: this change is not directly intended to avoid\n\u003e \"incidents\". It will take way too long to deploy this. Software should\n\u003e deal with malleability. This is a longer-term solution intended to\n\u003e provide non-malleability guarantees for clients that a) are upgraded\n\u003e to use them  b) willing to restrict their functionality. As there are\n\u003e several intended use cases for malleable transactions (the sighash\n\u003e flags pretty directly are a way to signify what malleabilities are\n\u003e *wanted*), this is not about outlawing malleability.\n\u003e \n\u003e While we could right now make all these rules non-standard, and\n\u003e schedule a soft fork in a year or so to make them illegal, it would\n\u003e mean removing potential functionality that can only be re-enabled\n\u003e through a hard fork. This is significantly harder, so we should think\n\u003e about it very well in advance.\n\u003e \n\u003e About new transaction and block versions: this allows implementing and\n\u003e automatically scheduling a softfork without waiting for wallets to\n\u003e upgrade. The non-DER signature change was discussed for over two\n\u003e years, and implemented almost a year ago, and we still notice wallets\n\u003e that don't support it. We can't expect every wallet to be instantly\n\u003e modified (what about hardware wallets like the Trezor, for example?\n\u003e they may not just be able to be upgraded). Nor is it necessary: if\n\u003e your software only spends confirmed change, and tracks all debits\n\u003e correctly, there is no need.\n\u003e \n\u003e -- \n\u003e Pieter\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 496 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140220/d16136fe/attachment.sig\u003e"}