Not a protocol fault: MtGox and transaction malleability
blog.oleganza.com
blog.oleganza.com
Bitcoin is a protocol in the sense that the IE6 rendering engine is a protocol: yes, rigorously examining what the client monoculture does and does not emit does allow you to describe some set-of-rules. Trying to create another Bitcoin client which attempts to agree with that set of rules is, ahem, fraught. You have to be bug-for-bug compatible with the Satoshi client implementation, not with the Satoshi client's declared behavior, design intent, or whatever constellation of PDFs and Wiki posts that the Bitcoin community anoints as "the protocol."
1. In 2009 when they fixed OP_RETURN and OP_CODESEPARATOR bug allowing to spend anyone's coins.
2. In 2010 when integer overflow created billions of BTC in one tx.
3. In 2012 when "OP_HASH160 <hash> OP_EQUAL" script was redefined to be interpreted as a hash of a script (see BIP16, Pay-to-Script-Hash aka "P2SH").
4. In 2013 when v0.8/v0.7 difference in database engines caused half of the network mine parallel blockchain due to obscure limit on number of file handles. The fix which was gradually introduced after reverting "incompatible" (although, longer) chain, was changing the protocol in a hard way.
The takeway from this: there's no parallel universe where a clearly defined spec in English is how all software operates to produce exactly the same blockchain. The most precise description would be a computer code itself running on the same hardware everyone uses. Anyone coming up with a "spec" of Bitcoin will only have a "description", not a "prescription".
(Ridiculous thought experiment: One user controls 75% of bitcoin and will buy and sell them only for $5. Given enough dollars desiring bitcoin he would quickly be reduced to 0% control, but in the meantime everyone else would have some difficulty selling for much more than $5.)
(realistically, I think the outcome of an unpatched fork is the collapse of bitcoin and people becoming very wary of anything claiming bitcoin in its genealogy (or even inviting close comparison to bitcoin))
(mostly because there are lots of humans involved and they will act like humans)
One: I think you understand "user" as mapping to hashpower-over-some-time-interval, but vanishingly few users of Bitcoin understand user to mean that. Two: if you control less than 50% of the hashpower over some time interval, you can with a certain probability and cost alter some rules of the protocol, and the consensus will back you. For example, there exists no rule amenable to 51% of Bitcoin hashpower currently that says "Transactions to addresses known to be controlled by Patio11 have a special property: they are not allowed on Tuesdays" but you can, in fact, impose that rule on the network without requiring 50% of the hashpower available on Tuesday. (It would be a pretty expensive thought experiment, depending on how certain you would want to be that the rule get adopted.)
Can I just highlight, for generic web developers who might not parse this sentence, that this is like saying "One of the ways we make sure all clients agree on HTTP is by making sure that all clients and servers stay on the same point release of Oracle DB because when they didn't for a few minutes the entire Internet died in fire. We put the fire out by reverting the Oracle DB version on a few big sites, telling everyone else to downgrade as well, and posting on an out of band channel that if you were doing anything important with the Internet you might want to stop for a few hours because there were going to be two separate and very mutually incompatible Internets and one of them was going to suddenly vanish a couple hours later and it sure would suck if your mail/web browsing/Dropbox/etc went into that one."
Seriously. That actually happened.
This sort of problem doesn't really occur on the web, so trying to draw an analogy to HTTP isn't going to help people understand the issue.
Please tell me, Patrick, that you're exaggerating and that Bitcoin doesn't work like this."
Guess what?
You're suggesting the Bitcoin protocol is badly designed because it's had problems that HTTP hasn't had. But this is like saying aeroplanes are poorly designed compared to cars because the latter don't fall out of the sky when their engines die. Planes have to deal with problems cars don't, not because of poor design, but because of the nature of what they're made to do.
Bitcoin concerns itself with providing data integrity across a distributed system. The only way of doing this, without a centralised server, is to ensure that all the clients are performing the same calculations. If it turns out a significant proportion of clients are performing the wrong calculation, then you have a problem. This isn't a problem inherent to Bitcoin; it's a problem with any distributed system trying to maintain a consistent database.
This is not correct, it is what half-plus-one of the users agree to. 100% is not a requirement.
Mt. Gox could fix the issue themselves without a change to the protocol by tracking the entire transaction, not just the hash.
If they don't do this, then we must ask why not? Could it be that they've lost so much Bitcoin to double-withdraws that they can't fill new withdrawal requests?
Would Mt. Gox benefit from a steep decline in the price of Bitcoin, so they can fill the gap at a lower cost?
What's a logical explanation of their behavior?
> If you need a quick answer: there’s no bug in the Bitcoin itself.
> Is it a design issue in Bitcoin to allow slight changes in the transactions? Yes, probably is.
This page has been there for at last 1 year: https://en.bitcoin.it/wiki/Transaction_Malleability
But it is interesting evaluating the commentary given that people who have a vested interest in Bitcoin will naturally have a very strong reason to defend the protocol and fundamentals (the linked submission even encourages readers to go buy into the hype at a "huge discount"). This is something you see on equity trading boards, the guy deep underwater on the penny stock loudly defending all fundamentals of his choice.
> aside from cryptocurrencies, there really is no other situation where the fact that you can take a valid signature and turn it into another valid signature with a different hash is a significant problem, and yet here it’s fatal.
http://blog.ethereum.org/2014/02/09/why-not-just-use-x-an-in...
There is no amount of time to wait until a bitcoin transaction is considered dead. Once its been communicated over the network, one has to assume it can be redeemed (incorporated into the blockchain) anywhere from never to a thousand years from now. Checking for txid even without malleable transactions is not helpful.
If a bitcoin payment has been issued, and a customer wishes it to be re-issued, the (only?) safe approach is to move the entire address contents to a new address, wait for that to hit the blockchain, and reissue the payment from the new address.
When different customer's balances are mixed in the same address, things get more difficult, and seeing as how its customary to pull balances from multiple addresses to satisfy the inputs a single transaction, I think mtgox has a claim to complexity beyond their ability to fix without help from the protocol itself.
As far as being affected by malleable transactions, an exchange should have a value on their 'books' for each customer and a value in the 'bank'/wallet for each customer. By keeping track of each set of addresses for each customer, like bitcoind does in its wallet, the two can be audited with each new block on the chain.
Let's imagine a future world where all monetary transactions go through Bitcoin. So the only way for me to find out if my transaction took place is to search the list of every worldly transaction to spot mine?
Obelisk, written by the libbitcoin people, provides an address/transaction tracking system over the network that could be used if bitcoind does not meet requirements.
Basically, this fix has been in place for a long time everywhere aside from MtGox.
(blockchain.info essentially does this for every address appearing in the blockchain)
But yeah, bitcoin as implemented is way to complicated to want to deal with all the time, everyday.
Technically, there might be collisions with hashes, they're in no way unique... Though the probability is rather low.
Anyways, this is a nice explanation of the real issue.
This doesn't seem ideal.
It's a simple solution to a simple problem, and it's pretty telling that Gox had this problem to begin with (but doesn't surprise me at all).
Can you come up with circumstances in which someone might choose to make successive transactions of the same value? Especially if that might confuse the issue?
You want to be able to tell if _this_ transaction completed, not if, say "A transaction that really looks like this one" completed.
What is the recommended solution by bitcoin implementers to verify a transaction succeeded, with transaction malleability existing ?
http://sourceforge.net/mailarchive/message.php?msg_id=319565...
I love this teleological market-speak.
http://i.imgur.com/ScHaDyl.png
How many coins was the US government holding? It would have to be someone not paying attention or not their money.
Huh?
> If you really need to track transactions in the way MtGox is doing, you should construct your own transaction ID that hashes everything except the scriptSigs (which are malleable).
Yeah. Except the Bitcoin network also apparently produces its own hashes of transactions and those hashes include mutable data leading to undesirable situations like hash(txn1) != hash(txn2) even though txn1 == txn2. It's like hashing people by their name and age instead of name and date of birth. Next year you won't find them in your table because their age is different.