rich1.0npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwethttps://nostr.ae/npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwetnjumphttps://nostr.ae📅 Original date posted:2014-02-10 📝 Original message:On Mon, Feb 10, 2014 at 3:28 AM, Drak <drak at zikula.org> wrote: > What is the official response from the Bitcoin Core developers about MtGox's > assertion that their problems are due to a fault of bitcoin, as opposed to a > fault of their own? > > The technical analysis preluding this mess, was that MtGox was at fault for > their faulty wallet implementation. In the real world fault seldom falls in a single place. Bitcoin is at fault— in many places— for making it harder for implementers to get things right. MtGox is at fault for not implementing in a way that copes with behaviors in the Bitcoin protocol which have been known since at least 2011. (https://en.bitcoin.it/wiki/Transaction_Malleability). Not that Bitcoin-QT handles Malleability fantastically— but because it tracks inputs it will still detect the mutant transactions. An interesting point which I haven't pointed out elsewhere is that for the question of basic funds safety in re-issuing a transaction mallablity is basically irrelevant. Say you pay someone and it doesn't go through (or it does and you don't see it because its been mutated and your software can't detect that), and they ask you to reissue.... if you reissue without double-spending any of the original inputs you are at risk of getting robbed. This is true with or without malleability. Without the double-spend of at least one input the original transaction could just go through in addition to your reissue. Say that you do make sure to double spend at least one input— then the result is funds safe safe, regardless of if a mutation happened. Say you want to support _canceling_ a payment (send me the goat instead!) rather than reissue you still must double-spend the attempted payment to cancel it, since it still might go through if you don't. And the double spend works to protect this case regardless of if the transaction was mutated. For support and accounting purposes you absolutely do need tools to identify mutated transactions, so long as mutation exists... so we ought to provide some better tools there. But I can't think a case where mutation handling is necessary or sufficient for cancellation security, but— rather— input tracking appears to be both necessary and sufficient in all cancellation cases. This helps explain why Bitcoin-QT— whos mutation handling kinda stinks— doesn't ever end up in a really bad situation with mutants: it tracks inputs pretty well. In any case, I've always been happy to help out Mtgox with technical issues. Having some specs for a stable transaction ID would probably be helpful to many applications, even if it isn't the critical key you need for cancellation security. Removing mallability entirely has been a soft long term goal, and there were recently (as in today) some posts about it— look at the list archives... though it won't happen fast since all signers/wallets will need to be updated.