Posted on 7 Comments

Dread Pirate Roberts Supporters Thrown for a Moral Loop

The radical libertarian world was just hit with a bombshell revelation the other day. Previously, the defense team of Ross Ulbricht surprised us by admitting that Ross was the originator of Silk Road, however they claim that Ross left the position after only a few months, handing it off to another entity. This “real” Dread Pirate Roberts, the one who ran the site for the the bulk of the time, eventually went on to drag Ross back in to frame him when he felt the heat from the Feds. Well, now the plot thickens; the defense team is naming a name: long time MtGox operator Mark Karpelès, the one who held the reins when it collapsed and who a lot of people are bitter towards. Furthermore, they have evidence to that end, as a federal agent testified that Mark was their original lead before they went after Ross.

This initially seems like a cause for small celebration. Here is a chance that Ross Ulbricht can be free, or at least substantially reduce the sentence he is liable to receive. But let’s slow down for a second because I think we’ve lost a little moral clarity here. It seems that at a certain point, the focus drifted from supporting the alleged heroic operator of the legendary Silk Road marketplace to supporting one Ross Ulbricht. Only allegedly the same thing, as some libertarians are quick to point out. According to the defense team of our hero Ross, the “real” Dread Pirate Roberts, operator of Silk Road marketplace, is Mark Karpelès. Well, if we’re in this because we support the Silk Road, shouldn’t our support now turn toward Mark?

There are now only two approaches to take with regard to Mark. Either we can be happy he is taking the heat off of Ross or not happy. Suppose we’re happy. This is, after all, a guy who ran MtGox into the ground, caused many people to lose a lot of bitcoin, and, as some suspect, even ran off with a lot of btc himself. Even if we don’t support people going to jail for facilitating drug sales, we can perhaps be content in this sort of poetic justice. If Ross, the human being, is found not guilty or responsible for being Silk Road’s operator, we still of course can cheer that an innocent man is allowed to be free, or have a reduced sentence for his reduced role. But wait – then we’re conceding that the real heroic Dread Pirate Roberts, operator of the legendary Silk Road marketplace, is in fact not a hero. Suddenly we’re happy to see him behind bars. Remember how defensive we were when Ross was charged with soliciting a murder-for-hire? As our focus has turned toward our sympathy for Ross, the human being, we may have forgotten what we originally supported: The idea of a free market pioneer, morally true, despite and even because of complete disregard for the law.

Okay, so suppose we’re willing to forgive Mark the transgressions from MtGox, and not hold it against him in his capacity as the DPR. Suppose the murder-for-hire charge doesn’t apply to him, either. Or maybe he wasn’t the DPR in the first place. In that case, we still don’t have such a cause to celebrate this latest move from Ross’ defense team. It just transferred most of the heat from one innocent man to another. But it’s even worse than that, because now, Ross, our libertarian folk hero, the one who still started the Silk Road, is in fact a snitch who just fingered an innocent man, possibly the heroic real Dread Pirate Roberts. This is not at all to say that I wouldn’t forgive Ross for doing so, nor that I wouldn’t do the same thing under the circumstances. However it does hurt our cause for having supported him in our ideological capacity, and taint the minor hero status that he’d still earned for starting the site and running it a few months. At the very least it may send a mixed message if we continue to support Ross under this favorable view of Mark.

I suppose the best possible outcome, from a libertarian stance, is that Ross knows Mark had nothing to do with Silk Road and the Feds have nothing on him, but Ross’s defense team still uses him to create enough reasonable doubt to set Ross free. Seems a bit of a long shot, though. But really, this is not a great situation in liberty land.

Posted on 11 Comments

MtGox Problems and Transaction Malleability

[Update below]

Watching the drama surround MtGox in recent days has been like watching a slow motion train wreck. It’s put a lot of strain on the community and has been causing the Bitcoin price to tank. If you’re not up to date on this story, basically MtGox has been experiencing severe Bitcoin withdraw issues with numerous customers claiming they never received their bitcoins. Apparently upwards of $38 million worth of bitcoin withdrawals have gone unfulfilled causing MtGox to freeze withdrawals altogether.

You can add this to the long list of problems MtGox has had over the last couple years. A trading platform that couldn’t handle high volume trades, operating without a license in the US and having a large amount of customer funds stolen by the US government, USD withdrawals taking months to clear, and strong suspicion it’s operating on fractional reserves.

Now this morning MtGox comes out and announces its problems aren’t its fault, but rather a bug in Bitcoin itself! News of this potentially catastrophic bug has sent the markets into a tizzy.

So what bug are they talking about exactly? It has to to do with something called transaction malleability. Now, this isn’t some kind of zero-day exploit. It has been known since at least 2011. Fixing it has never been high priority for the developers because, as we’ll see, it hasn’t been considered that big of a deal. Which is why it’s a bit odd that that MtGox would claim this is the source of their problems.

So what is this attack specifically? Basically it amounts to altering a transaction after it has been broadcast. A Bitcoin transaction has a number of parts:

version 01 00 00 00
input count 01
input previous output hash
(reversed)
48 4d 40 d4 5b 9e a0 d6 52 fc a8 25 8a b7 ca a4 25 41 eb 52 97 58 57 f9 6f b5 0c d7 32 c8 b4 81
previous output index 00 00 00 00
script length 8a
scriptSig 47 30 44 02 20 2c b2 65 bf 10 70 7b f4 93 46 c3 51 5d d3 d1 6f c4 54 61 8c 58 ec 0a 0f f4 48 a6 76 c5 4f f7 13 02 20 6c 66 24 d7 62 a1 fc ef 46 18 28 4e ad 8f 08 67 8a c0 5b 13 c8 42 35 f1 65 4e 6a d1 68 23 3e 82 01 41 04 14 e3 01 b2 32 8f 17 44 2c 0b 83 10 d7 87 bf 3d 8a 40 4c fb d0 70 4f 13 5b 6a d4 b2 d3 ee 75 13 10 f9 81 92 6e 53 a6 e8 c3 9b d7 d3 fe fd 57 6c 54 3c ce 49 3c ba c0 63 88 f2 65 1d 1a ac bf cd
sequence ff ff ff ff
output count 01
output value 62 64 01 00 00 00 00 00
script length 19
scriptPubKey 76 a9 14 c8 e9 09 96 c7 c6 08 0e e0 62 84 60 0c 68 4e d9 04 d1 4c 5c 88 ac
block lock time 00 00 00 00

The transaction is run through a hash function with the resulting output looking something like this:

81aefec8ce0fd59f5baf42096ba3e0e529dbef49d4dd3228e5f24b2acf3dd8f2

This hash serves as the transaction ID and can be referred to when referencing the transaction.

Transaction malleability makes it possible to alter the scriptSig field in the transaction in a way that does not invalidate the transaction, but does change the transaction ID.

This does NOT mean an attacker can forge a transaction. It doesn’t mean an attacker can swap out the receiving addresses or double spend bitcoins. If this attack is performed, the transaction still goes through as normal. The bitcoins still end up at the proper location. All it does is alter the transaction ID. To the sender it would look as if the transaction never confirmed, even though it did. (Note this affects all copy-and-paste altcoins as well.)

How is this affecting MtGox? Basically, MtGox logs the transaction ID for every withdrawal. They are claiming that someone is placing withdrawals then using transaction malleability to alter the transaction ID and make it look to MtGox like the withdrawal didn’t go through even though it did. Then, presumably, trying to get MtGox to reimburse them.

I should mention that this is a relatively difficult attack to pull off. An attacker would need to see to it that the altered transaction makes it into the next block and not the original transaction. Since miners accept the first transaction they receive as valid and since MtGox broadcasts the transaction to the network, it is significantly more likely the original transaction will be seen by miners first and make it into the next block.

The attacker would need to see the transaction before the vast majority of miners, then relay the altered transaction to a large number of miners and hope his transaction propagates quicker than the original. Not something your average person can do.

Now as MtGox mentions, if the altered transaction doesn’t make it into a block, the attacker can just redeposit the coins and try again.

So that’s what they claim is going on. However, from my armchair perspective I’m still a little skeptical. Let me give my reasons.

  1. Even though the transaction ID has been altered, it’s still relatively easy to tell that the transaction went through. Just look at the receiving address and check to see if it received any transactions for the same amount of bitcoins. If so, check to see if the input address matches MtGox’s address. If done correctly, transaction malleability isn’t a problem at all.
  2. AML/KYC regulations require MtGox to record the identity of all its customers. To use the exchange you have to provide a government issued ID. In other words, MtGox would know who was doing this attack. I suppose this person could plausibly claim ignorance, but would you try to scam a company using an account linked to your identity?
  3. I suppose an attacker could be doing this to other people’s withdrawals, maybe in an attempt to create chaos and drive down the price. But even here, people would still receive their bitcoins as requested. Remember we had widespread reports of people not receiving any bitcoins. It seems unlikely to me that people would complain like that if the withdrawal actually went through.

So my gut tells me there are other problems with MtGox that we still don’t know about. Transaction malleability could be a problem, but it’s an easy fix for them. Either way people need to understand that Bitcoin is not broken. These are much more MtGox problems than Bitcoin problems.

Here’s what core developer Pieter Wuille wrote this morning on the developer mailing list:

Hi all,

I was a bit surprised to see MtGox’s announcement. The malleability of
transactions was known for years already (see for example the wiki
article on it, https://en.bitcoin.it/wiki/Transaction_Malleability it,
or mails on this list from 2012 and 2013). I don’t consider it a very
big problem, but it does make it harder for infrastructure to interact
with Bitcoin. If we’d design Bitcoin today, I’m sure we would try to
avoid it altogether to make life easier for everyone.

But we can’t just change all infrastructure that exists today. We’re
slowly working towards making malleability harder (and hopefully
impossible someday), but this will take a long time. For example, 0.8
not supporting non-DER encoded signatures was a step in that direction
(and ironically, the trigger that caused MtGox’s initial problems
here). In any case, this will take years, and nobody should wait for
this.

There seem to be two more direct problems here.
* Wallets which deal badly with modified txids.
* Services that use the transaction id to detect unconfirming transactions.

The first is something that needs to be done correctly in software –
it just needs to be aware of malleability.

The second is something I was unaware of and would have advised
against. If you plan on reissuing a transaction because on old version
doesn’t confirm, make sure to make it a double spend of the first one
– so that not both can confirm.

I certainly don’t like press making this sound like a problem in the
Bitcoin protocol or clients. I think this is an issue that needs to be
solved at the layer above – the infrastructure building on the Bitcoin
system. Despite that, I do think that we (as a community, not just
developers) can benefit from defining a standard way to identify
transactions unambiguously.

UPDATE: Rick Falkvinge has provided a good summary of the problems:

Here’s the real problem: MtGox is running its own homebuilt bitcoin software, and has not cared to update and upgrade that software along with the developments of the bitcoin protocol. Recently, after a very long grace period, the bitcoin protocol tightened slightly in order to disallow unnecessary information in transaction records, and did this to fix the malleability problem that MtGox blamed.

So the problem of malleability remained at MtGox, while having been fixed in the rest of the world. This – the discrepancy itself – was the root cause of the problem, because it meant that MtGox started issuing invalid transaction records for bitcoin withdrawals. Obviously, they were rejected by the bitcoin network.[…]

What this means is that MtGox wasn’t the subject of some skilled hacking related to transaction malleability. Instead, bad code hygiene was causing MtGox to broadcast invalid transactions, which could trivially be corrected and re-broadcast, causing all these problems downstream.

Original content by Chris, copyleft, tips welcome