Hacker News Reader

Comment by pstrateman | Hacker News Reader

The claim that this was caused by transaction malleability rings hollow.

The reference client (github.com/bitcoin/bitcoin) does not resend transactions because of malleability.

The only way you can have double transfers due to malleability is if you are manually reviewing transfers and re-sending them yourself manually.

This seems like a very convenient scapegoat.

View on HN

Yeah. The moment I got to " a vendor exploited a recently discovered vulnerability in the Bitcoin protocol known as “transaction malleability”" I was like "Riiiiight....".

It's not even 'recently discovered', and as far as I understand it it does not let anyone to drain other persons' wallet (if it did, that'd be a killer to entire bitcoin the moment it was discovered)

They wanted to exit the business from the start. Saw a convenient time with everyone discussing a vulnerability, claim right away that vulnerability was used to steal all the money to avoid backlash from users.

If one were sufficiently cynical one could argue that this was the plan from the start. Build another version of the site, wait for some BitCoin disaster, take all the funds and claim it was the disaster that done did it.

Of course to pull that off you'd really need to employ the disaster yourself so that you have the ledger entries to "prove" it.

Don't need to be cynical: that has happened with multiple other markets. I think that's exactly what happened here.

Why would you care about backlash from users? It's Tor. You can just disappear forever.

Tor != can disappear forever and completely untraceable. The marketplace they have set up is often used to sell illegal items and substances. I would imagine there is a high percentage of those involved that if they found out who is behind and Silkroad 2.0 owners plainly and simply said -- "haha, I got your money now, too bad" would put enough resources into tracking them down and physically injuring them.

It just makes sense for them to mitigate risk and having a plausible "hey this recent vulnerability killed us, sorry, go read about in the news, it is bad..." excuse perhaps does that.

I doubt drug dealers care about the distinction between "you stole my money" vs. "you lost my money". Either case SR2 admin better do a good job of hiding.

You think if they didn't do a reasonable job of hiding they wouldn't be caught by say, the government?

The government waits until they have a good case against you before arresting, drug dealers do not.

From my understanding of the malleability issue, couldn't you have vendor withdrawals that get sent, but then not verified by the Silk Road system? Where the original transaction gets rejected due to the modified one getting accepted by the network? So then the Silk Road internals would assume it just didn't go through and not deduct it from the vendor's internal balance, allowing the vendor to repeatedly withdraw as long as they just withdrew their whole balance and modified the transaction each time?

Implementing a system to detect transactions being confirmed is orders of magnitude more complicated than send and forget.

I've sent literally tens of thousands of bitcoins transactions and have never once had a transaction that wasn't confirmed within 48 hours.

The important part here is that I have always used the reference client with the latest ruleset for transaction fee calculation.

It might have been scripted to automatically resend the Bitcoin. This would be a huge oversight, but it is not beyond a doubt.

It's recently been suggested that it actually is possible to drain someone's wallet using transaction malleability, if they are not using the reference software. See below:

https://anders.io/the-troublesome-history-of-the-bitcoin-exc...

I thought the 'malleability' problem only resulted in miners being DDOS'd. The transactions themselves were supposedly still 'intact' - i.e., inputs, outputs, addresses were not modified.

So.... what are SR2 saying happened here? - Is it a double spend using SR2 escrow bitcoins? - How was the malleability introduced?

There are two potential issues with the malleability. One is the MtGox problem where you might not realize a transaction was successful and you are duped into sending the money twice.

The second issue is a bug that was discovered in the reference client where if you try to spend coins you sent to yourself before they are confirmed a bug in the wallet causes your balance to be off.

Neither problem inherently allows theft but if you aren't careful the first can open your to social engineering. The reason they are calling this a dos as far as I can tell is because they are preventing you from spending your money until the bug is fixed with the accounting in the reference wallet.

SR2 is probably full of crap but there is a small possibility that they some how automated re-sending of failed transactions w/o properly accounting for malleability in which case you might be able to steal a multiple of the actual amount of money in your account over a few days. The sheer size of this though would make me skeptical of that scenario.

> One is the MtGox problem where you might not realize a transaction was successful and you are duped into sending the money twice.

This isn't really a malleability issue however. Lets say it wasn't successful: You send again. Opps, someone pulls the original out of a hat and both go through.

The only way to safely reissue is to double spend the original transaction. Then you get atomic exclusion, and it's completely safe: only one can possibly get into the longest chain. This safety still applies if there is mutation going on.

The "hack" would involve withdrawing money, changing the hash of the transaction and then complaining that the transaction didn't go through. This was done through the support channels on Mt. Gox etc but technically could have been an automated system on silk road 2. Not likely though.

MTGox's reissuing was automated and running on a timer, fwiw.

I think the idea would be that you would withdraw from escrow, manipulate the transaction to change the transaction id (which they shouldn't be relying on if they use bitcoind and makes the whole thing kinda fishy) then when SR can't find the transaction it assumes it failed and sends again or he opens a ticket saying he never got his funds and they send them again manually.

> The only way you can have double transfers

Is if you replace the transaction without double spending it, which is unsafe.

Reply on news.ycombinator.com