{"type":"rich","version":"1.0","author_name":"npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwet","author_url":"https://nostr.ae/npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwet","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-02-10\n📝 Original message:On Mon, Feb 10, 2014 at 3:28 AM, Drak \u003cdrak at zikula.org\u003e wrote:\n\u003e What is the official response from the Bitcoin Core developers about MtGox's\n\u003e assertion that their problems are due to a fault of bitcoin, as opposed to a\n\u003e fault of their own?\n\u003e\n\u003e The technical analysis preluding this mess, was that MtGox was at fault for\n\u003e their faulty wallet implementation.\n\nIn the real world fault seldom falls in a single place. Bitcoin is at\nfault— in many places— for making it harder for implementers to get\nthings right.   MtGox is at fault for not implementing in a way that\ncopes with behaviors in the Bitcoin protocol which have been known\nsince at least 2011.\n(https://en.bitcoin.it/wiki/Transaction_Malleability).\n\nNot that Bitcoin-QT handles Malleability fantastically— but because it\ntracks inputs it will still detect the mutant transactions.\n\nAn interesting point which I haven't pointed out elsewhere is that for\nthe question of basic funds safety in re-issuing a transaction\nmallablity is basically irrelevant.\n\nSay you pay someone and it doesn't go through (or it does and you\ndon't see it because its been mutated and your software can't detect\nthat), and they ask you to reissue.... if you reissue without\ndouble-spending any of the original inputs you are at risk of getting\nrobbed. This is true with or without malleability.  Without the\ndouble-spend of at least one input the original transaction could just\ngo through in addition to your reissue.\n\nSay that you do make sure to double spend at least one input—  then\nthe result is funds safe safe, regardless of if a mutation happened.\n\nSay you want to support _canceling_ a payment (send me the goat\ninstead!) rather than reissue you still must double-spend the\nattempted payment to cancel it, since it still might go through if you\ndon't.  And the double spend works to protect this case regardless of\nif the transaction was mutated.\n\nFor support and accounting purposes you absolutely do need tools to\nidentify mutated transactions, so long as mutation exists... so we\nought to provide some better tools there.  But I can't think a case\nwhere mutation handling is necessary or sufficient for cancellation\nsecurity, but— rather— input tracking appears to be both necessary and\nsufficient in all cancellation cases.\n\nThis helps explain why Bitcoin-QT— whos mutation handling kinda\nstinks— doesn't ever end up in a really bad situation with mutants: it\ntracks inputs pretty well.\n\nIn any case, I've always been happy to help out Mtgox with technical\nissues. Having some specs for a stable transaction ID would probably\nbe helpful to many applications, even if it isn't the critical key you\nneed for cancellation security.  Removing mallability entirely has\nbeen a soft long term goal, and there were recently (as in today) some\nposts about it— look at the list archives... though it won't happen\nfast since all signers/wallets will need to be updated."}