{"type":"rich","version":"1.0","author_name":"npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","author_url":"https://nostr.ae/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-02-19\n📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA256\n\nWhile we might be able to get away with a retroactive change in meaning right now in the future that won't be so easy. There are lots if proposed applications for nLockTime-using protocols that depend on transactions (or parts of transactions) being possible to mine as is. Making existing transactions impossible to mine in the future will break those types of applications. We might as well use this as a learning experience for what a version bump would look like infrastructures wise.\n\nNote how the above is a particularly bad example of gmaxwell's generic \"don't break things\" objection. Equally, remember that lots of infrastructure *does* handle malleability just fine already.\n\nOn February 19, 2014 3:28:24 PM EST, Michael Gronager \u003cgronager at mac.com\u003e wrote:\n\u003eTwisting your words a bit I read:\n\u003e\n\u003e* you want to support relay of transactions that can be changed on the\n\u003efly, but you consider it wrong to modify them.\n\u003e* #3 is already not forwarded, but you still find it relevant to\n\u003esupport it.\n\u003e\n\u003eRational use cases of #3 will be pretty hard to find given the fact\n\u003ethat they can be changed on the fly. We are down to inclusion in blocks\n\u003eby miners for special purposes - or did I miss out something?\n\u003e\n\u003eI think that we could guarantee fewer incidents by making version 1\n\u003etransactions unmalleable and then optionally introduce a version 3 that\n\u003esupported the malleability feature. That way most existing problematic\n\u003eimplementations would be fixed and no doors were closed for people\n\u003eexperimenting with other stuff - tx v 3 would probably then be called\n\u003eexperimental transactions.\n\u003e\n\u003e/M\n\u003e\n\u003e\n\u003eOn Feb 19, 2014, at 3:38 PM, Pieter Wuille \u003cpieter.wuille at gmail.com\u003e\n\u003ewrote:\n\u003e\n\u003e\u003e On Wed, Feb 19, 2014 at 3:11 PM, Michael Gronager \u003cgronager at mac.com\u003e\n\u003ewrote:\n\u003e\u003e\u003e Why introduce a new transaction version for this purpose ? Wouldn't\n\u003eit be more elegant to simply let:\n\u003e\u003e\u003e\n\u003e\u003e\u003e 1. the next bitcoin version \"prettify\" all relayed transactions as\n\u003edeterministic transactions fulfilling the scheme 1-6 effectively\n\u003eblocking any malleability attack? If miners would upgrade then all\n\u003etransactions in blocks would have a deterministic hash.\n\u003e\u003e\n\u003e\u003e I consider actively mutating other's transactions worse than not\n\u003e\u003e relaying them. If we want people to make their software deal with\n\u003e\u003e malleability, either will work.\n\u003e\u003e\n\u003e\u003e Regarding deterministic hash: that's impossible. Some signature hash\n\u003e\u003e types are inherently (and intentionally) malleable. I don't think we\n\u003e\u003e should pretend to want to change that. The purpose is making\n\u003e\u003e non-malleability a choice the sender of a transaction can make.\n\u003e\u003e\n\u003e\u003e Most of the rules actually are enforced by IsStandard already now.\n\u003e\u003e Only #1 and #7 aren't. #1 affects the majority of all transactions,\n\u003eso\n\u003e\u003e changing it right now would be painful. #7 only affects multisig.\n\u003e\u003e\n\u003e\u003e\u003e 2. In a version later one could block relay of non deterministic\n\u003etransactions, as well as the acceptance of blocks with non-confirming\n\u003etransactions.\n\u003e\u003e\u003e\n\u003e\u003e\u003e To non-standard conforming clients this \"prettify\" change of hash\n\u003ewould be seen as a constant malleability attack, but given the\n\u003e\"prettify\" code it is to fix any client into producing only conforming\n\u003etransactions, just by running the transaction through it before\n\u003ebroadcast.\n\u003e\u003e\u003e\n\u003e\u003e\u003e There is a possible fork risk in step 2. above - if a majority of\n\u003eminers still havn't upgraded to 1 when 2 is introduced. We could\n\u003emonitor % non conforming transaction in a block and only introduce 2.\n\u003eonce that number is sufficiently small for a certain duration -\n\u003ecriteria:\n\u003e\u003e\u003e * Switch on forcing of unmalleable transactions in blocks when there\n\u003ehas been only conforming transactions for 1000 blocks.\n\u003e\u003e\n\u003e\u003e The problem in making these rules into consensus rule (affecting\n\u003e\u003e tx/block validity) is that some rules (in particular #3) may not be\n\u003e\u003e wanted by everyone, as they effectively limit the possibilities of\n\u003ethe\n\u003e\u003e script language further. As it is ultimately only about protecting\n\u003e\u003e senders who care about non-malleability, introducing a new\n\u003etransaction\n\u003e\u003e version is a very neat way of accomplishing that. The new block\n\u003e\u003e version number is only there to coordinate the rollout, and choosing\n\u003e\u003e an automatic forking point.\n\u003e\u003e\n\u003e\u003e --\n\u003e\u003e Pieter\n\u003e\n\u003e\n\u003e\n\u003e------------------------------------------------------------------------\n\u003e\n\u003e------------------------------------------------------------------------------\n\u003eManaging the Performance of Cloud-Based Applications\n\u003eTake advantage of what the Cloud has to offer - Avoid Common Pitfalls.\n\u003eRead the Whitepaper.\n\u003ehttp://pubads.g.doubleclick.net/gampad/clk?id=121054471\u0026iu=/4140/ostg.clktrk\n\u003e\n\u003e------------------------------------------------------------------------\n\u003e\n\u003e_______________________________________________\n\u003eBitcoin-development mailing list\n\u003eBitcoin-development at lists.sourceforge.net\n\u003ehttps://lists.sourceforge.net/lists/listinfo/bitcoin-development\n-----BEGIN PGP SIGNATURE-----\nVersion: APG v1.0.9\n\niQFQBAEBCAA6BQJTBRjcMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8\ncGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhbuuCADHHZvCbWNR+hj3lq2u\nXjr8POSsMWk4XorvLftgXSzAzypr7n0BP7+fmz/v0J98XfeOHxf8NHB2VXzFMCzI\nmstYyFC+gdsPf9eIMoN2S9EB9d4Lh1Y7Zv5BGqopuHCUIVMpzk2QDaFlLe+gW8Ai\np4Yv/jGib8ym1ahJ24nZ89l7Psa+uXDw8N2VX5PcyDNVRwzuXwa0h2Kix/gt8uJb\nRV5Sj3duxUE6mOGN07j6lPu9VcrtD0ydvAO3DoEJqkBqjhbC33h05H96KPQKuGcg\n5DOKXUV5ChW5CF3DH5HN/LdduLgbTevtLbkBhdLKo+z5GKaU7Qpc5i6dIeAKl3uA\nKCQE\n=DiAE\n-----END PGP SIGNATURE-----"}