Home » Articles » Here is the Stolen Silk Road Wallet?
Click Here To Hide Tor

Here is the Stolen Silk Road Wallet?

This is an interesting read that was posted as an item on Silk Road “money” category, we have been chatting with this vendor for the last few days and really tried to understand the evidence he is trying to provide here, and to be honest, it just made me very confused, so i decided to post this – so people that are more into the analysis of bitcoin transactions than me can read and decide for themselves if this information is real or not and what is the bottom line of all of this?

We would love to hear your comments on this matter. this is similar to the chase that happened after the sheep scam, and most likely by the same person (Sheeproadreloaded2) and some associates

The live listing is here: http://silkroad6ownowfk.onion/items/here-is-the-stolen-silk-rd-wallet
Reddit discussion is here: http://www.reddit.com/r/SilkRoad/comments/1yecja/the_hackers_btc_wallet_found/
Another interesting read about the “Hack” on bitcointalk.org  forums: https://bitcointalk.org/index.php?topic=463896.0;all

walletdfd

Wallet pic 2

===Start Quote===

——————————————————————————————-
BBMC is a full member of the British Tor Vendors Association (BTVA)
_________________________________________________________

Ever get the feeling you’ve been swindled?

https://blockchain.info/address/1GRFNTyLwoyQnk7S3MFFAz5qPkdWp7YSoY

They’ve been moving our bitcoins out of the site’s ” Fac” wallet since the end of January. Its only 5,770.000666 BTC

More interesting is all the 777s I’ve been finding associated with Silk Road from this wallet:-

https://blockchain.info/address/12Nxd2X12WZeYSjUcbtm5NpS3d81Yh8sKh

Each “777” payment marks a massive cashpile, there are 120 of them. The wallet has been busy again today. (19 Feb)
I believe the thief uses this wallet. I was worried that this info could compromise DPR;s trial, if it is bitcoin earned by him.

I’ve even tried to make myself known to the wallet owner by firing in the numbers for V-E-N-D-O-R-B-B-M-C- (using 1 to 26)
But Ross can’t be moving that money around, he’s in custody.

When Defcon claimed to be unable to find the escrow funds in December, I felt sorry for him, so I found as many SR2.0 system wallets as I could for him, marked them from the 1Ah wallet on Dec 24th, then messaged support to let them know where DPR2 kept the money.

https://blockchain.info/address/1AhYNAoMxDPD7bnNvxuSY9FB1CDviEuqzZ

On Thursday 13th Feb, my escrow went missing again at about 18:30 UK time, along with those of other UK vendors. Silk Road support had been specifically asked not to steal from any of the British Tor Vendors Association members. I was contacted by the BTVA, and asked to find our missing funds.

It was very easy, and easier because I already had wallets such as

https://blockchain.info/address/1Facb8QnikfPUoo8WVFnyai3e1Hcov9y8T

marked on 24 dec and 31 dec

The irony that a thief was using small 777 bitcoin payments to mark his own swag piles wasn’t lost on me.

The 777’ing wallet now has a 666 in it
Just go and add up a few of those hundreds of fat wallets, all filled, then marked with wallet

https://blockchain.info/address/12Nxd2X12WZeYSjUcbtm5NpS3d81Yh8sKh

in close succession.

I haven’t added it all up, but it looks around half a billion dollars move and marked in February. Most of that must be unspent historical Silk Road and SR2 earnings.

Whoever owns the android phone with bitcoin wallet 12Nxd is the thief (i believe). My money is on Defcon. And some of my money is WITH him. About 3 BTC.

If the thief hadn’t misappropriated it from the Brotherhood of British Meth Chemists, none of this need have happened

EDIT 20 Feb ****It was an inside job, but not the current staff. The same goes for Mt Gox. I believe it is a programmer who coded the Mt Gox wallets, the SR2 wallets, and also set up the gaming sites which have been spamming the bitcoin network with micropayments.

He hacked our investigator’s facebook in order to message him on Feb 11th, (which he was investigating before being contracted by us), using the name “Phibbo Bit”. This is the message:-

““Some background: MtGox runs custom wallet software.

This is a reasonable and common practice for a service of its size and nature.

Getting a wallet implementing right isn’t easy as there is very little room for error, much like the rest of the Bitcoin system.

Some have criticized their use of custom software here but it is a reasonable and common practice for a service of its size and nature. The reference client’s wallet is basically suitable for small scale single party use. I would not recommend something like MtGox use the reference node wallet, at least not without a healthy layer of abstraction on top of it— relieving it of duties harder than key management and chain monitoring— or otherwise improving it greatly.

(For that matter, MtGox’s wallet software has caused them fewer concerning problems than some other companies. (E.g. some have completely re-implemented the Bitcoin protocol, incorrectly, and exposed it to the outside world and suffered numerous local blockchain rejecting glitches). Though its certainly taken Gox a fair amount of time to sort things out.)

I first heard people reporting stuck transactions back in ~September. I looked into it and determined that Mtgox was spending immature coins. Freshly generated Bitcoins (from mining) can not be spend until they are at least 100 blocks deep in the blockchain. This prevents the funds from vanishing forever if the chain reorgs. I pinged magicaltux and after a couple tries got a hold of him. I think they also wasted some time on dead ends trying to resolve this before the actual nature of the problem was brought to their attention, e.g. raising their transaction fees with a mistaken belief that their fees weren’t high enough.

Mtgox wasn’t tracking if the coins were freshly generated or what their height was in their software. Including this data would apparently be a non-trivial change, and for high risk finance software even a trivial change takes a lot of work. I suggested a workaround (basically, just try to spend the oldest coins), and as far as I know they implemented it and it was effective.

They continued to have problems with stuck transactions after, and further analysis revealed that they were producing transactions with excessively padded signatures. A minor tangent is required here:

There is a design flaw in the Bitcoin protocol where its possible for a third party to take a valid transaction of yours and mutate it in a way which leaves it valid and functionally identical but with a different transaction ID. This greatly complicates writing correct wallet software, and it can be used abusively to invalidate long chains of unconfirmed transactions that depend on the non-mutant transaction (since transactions refer to each other by txid).

This issue arises from several sources, one of them being OpenSSL’s willingness to accept and make sense of signatures with invalid encodings. A normal ECDSA signature encodes two large integers, the encoding isn’t constant length— if there are leading zeros you are supposed to drop them.

It’s easy to write software that assumes the signature will be a constant length and then leave extra leading zeros in them.

In order to eventually remove this malleability flaw we’ve been gradually tightening the rules that govern what transactions nodes in the network will consider valid when they relay them or mine them. In Bitcoin 0.8— after months of work chasing down software authors to get them to fix their bugs transactions with these invalid encodings were no longer relayed.

This caused some problems for a few things.. For example bc.i’s iphone app— BC.i itself had been fixed long before but they couldn’t update the Iphone app without fear of triggering another review by Apple. Eventually this was just worked around on the server side by mutating the transactions produced by the iphone wallets. (And is moot now, I guess!).

MtGox also had problems with occasionally producing invalid signatures. This would normally be a simple fix. E.g. here is an example where I fixed this type of issue in some python wallet code I’ve never used (but saw a lot of people were copying): https://github.com/…/4c64603ab60b0fa23c51090b3112be2f16…

But as I said before, in high value systems like Mtgox, even simple fixes aren’t simple and it took them quite some time to deploy a fix. However, I believe that it is actually fixed now.

My current understanding and inference is that the remaining issues are because while MtGox was producing transactions of the bad form that the network won’t relay anymore— some people decided to help out by ‘fixing’ these transactions like BC.i did for iphone users— making the signatures normal and broadcasting them. Of course, the new transactions— while functionally identical— have different TXIDs.

The difference here is that the MtGox wallet software appears to have not handled this case gracefully at all, and apparently simply wouldn’t notice transactions that it “didn’t make” spending its own coins.

As a result the Mtgox wallet believed some coins were available for spending which really had already been spent and it began double spending those inputs. This may have interacted particularly poorly with the earlier workaround I mentioned— trying to always use the oldest available coins— if they did implement that workaround.

Worse, some of this may have resulted in users getting paid multiple times and could have been intentionally triggered with that end in mind if someone helpfully fixed some transactions and then noticed they got paid twice. (I think this is unlikely to have caused large losses, before people run off worrying about that, both because of the reuse of the oldest inputs and because of the hot wallet/cold wallet split).

At this point they likely have an accounting mess to clean up— figuring out who did and didn’t get paid now with none of the txids matching. Cleaning that up will be somewhat tricky E.g. say there were three payments of MtGox coins to 1Apple in the block chain… and three users that attempted to pay 1Apple, and MtGox’s records thinks that only one went through.. etc. So software will have to be written that matches up transactions with their mutants in order to figure out what went where.

I am not personally concerned— at least not by any of the details here. MtGox’s slow speed at resolving these sorts of issues and poor communications are not terribly inspiring. They seem to be horribly short staffed— but competent and trustworthy people in this space may be hard to find: The regulatory morass of that business is sure to make many steer clear.

The claims that the delays indicate insolvency strike me as just hysteria: the technical background doesn’t support this conclusion, and there may be a bit of opportunism at play from people who want to manipulate the market too. Don’t get me wrong: I have not seen their books: Gox may well have financial problems— though with their income its hard for me to see how— but if any problems like that exist they’re not being indicated here.

Of course, none of this suggests anyone should be happy with the service MtGox has been providing, but our anger should at least be well informed.

February 11 at 2:02am ”

(that wasn’t the UK time, it is from a copy saved by another recipient)

I still think Defcon is full of shit, with his “we will prevail” our community shit. But I don’t think the boy dunnit.”
—————————————————————————————–
Incidentally, this isn’t a real listing, don’t try to buy it! Feel free to make a small payment to any of those wallets. It will let the thief, or thieves, know that YOU know.
Have a great week everybody! Its only money

RedBook
The BBMC Team

===End Quote===

Are these chases going to lead to any of the funds being returned? i highly doubt it. but still its interesting information and should be known.

Good luck to everyone and be safe.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

Captcha: *