Bitcoin Forum

Hello,

there has been a lot of reused R values in the signatures on the blockchain, recently.  This exposed many private keys.  After googleing the addresses, I think it is related to Counterparty (XCP).  Here is a list of the exposed addresses in alphabetic order.  Most keys were exposed very recently, i.e., in the last week.

If you own one of the following addresses, you should transfer the money to a fresh address (before someone else does it for you).  Also figure out, which client has the bug that revealed the private key by reusing R values.  Then notify the author of that tool.

112KZ24UgNndZqdnu2cXwXStSjtY78ZRUh
12ZXAga2nRxBECsMDjFypWuL9UkKEaS4Z3
12sisxXmNPmFTpekBKEqZCELYXESPYUHCB
139YrtXS2J1KiD8pf2R3RtKRPr8sLwLuiq
13GSuGxtMZyE6SDA8XJyuWsHYpXZyNQTAn
13ikC8398HhciFWkqPCrRHWUBASGxhBY4m
13tRCNGCGuVN4gYyf6CpfYckhM3qrJy9YX
14Bgi1c11HBcj7krN5tRepMdL3SPghEaMM
14kaXa47cUcMpvKnCa8zr38C9v7sVPxSta
14qF25Rg3hJaYFHwE6ST2rr1cnBS3DPYNe
14uS988CkkfTs7Ckre8nkVedSQF9v4CqrM
1599DB5Tb1RWDPYMuU3YJT3jRwyyoPZa1B
15Ew6Sen8hVhTfLmXvAEEqGfX58iYWqEV5
15mcUhVMi3KmoWvP6Y8NpVaXaPVGCWztgL
1681LkMDLNw6CCjUrMojRKC8BaiwQ2LTFt
16LEKMzhabDoTghR2no3a59SJQC6MJp2aM
16NMGWRavnYG5bhWzY8GAXWiTZLytpT4v7
16khUbFwUK6X7U5X919RJeWyfBHSLfJMda
16vHYDZCLZiD97TucWr5Wht9zBA7JJmuF5
17SP6Qc3fP3zUWFkfRrwY3TF3a6eQ3NsZr
17Vxv31VfpFY6tWBBB93tcSgP4SYeqzTTb
17quWZhtGikUcTUpExchL6UdFga6Z8hME9
17xnTfrWYiLMhEQmW55VCa5cVhSZMVUak6
181ErGfBCT7twckweWJgoDMGXNepvb4qnp
185YGf4EoVfgqFBSAAUf1wDte9KVwmdHMy
187TT5PpAKGHRBGjdaKDZsgBH1s8yNCtS4
18RecXQxH8xuqS1zNgrukvPybDtc3Mn4br
18SEPGaZ3xdHiH2hkSdPgkYdnvzPr6PZYS
18U2grD3VwFa626tkTnabXSY2nVQAvmf3U
18W9kV7SqNPnvcbZRzM34aE14m5tFmAuz5
18djF84ZNVURvFUX2ZAVaFqV9MerjJkQtE
18mEp3aKQ9thp3H72rrzHAfW719YmHq2f7
199EPbUzU6mBr7dP61ihWsicuJyeYbJviS
19Ey6feEfARgzcNRmUxBZNQFYSmwgsU9Wc
19usDGaGtwHfMoJKAJEJd3KcfZFWj5zocV
19vokfKSJJMwHAqQ3Kehk8Gq5drXhi7wzU
1AApKu3su7VT9K1hgyxp3pcp2DSNC5V9s3
1AFZ8j6Mm6EphAFJbHyzCxKpKm9si8Vt3v
1AGCK1JM7pEu5r4g5yRiezXhn83TPGaWEh
1AKE18rv9BUPpxciQziTjQzwNQoMSrvQaV
1AX5hvrNXTs8KnDVBSRwHPHg5iQ5fyb8rs
1AjwULXBv9TeVjADC3khcP69USBGRXYUpd
1ArJ9vRaQcoQ29mTWZH768AmRwzb6Zif1z
1AsEhnbniTP4YSA8L1Xa1uQjfSfHbb8tzJ
1AsbDvSw2rzEa39erkCrMW6KTr4tDHGSAH
1Asfz56unNm1c527p3ENavRqecShQyxHeN
1B9FoQWdPift6CUXUs6K82TZxaTyHpTUnC
1BDMV3Yb6Pp2ycB94UsruXgPWAWBJhBuKL
1BYuQ21smrF1hKfmHPsDnJkWZZdEpBFLZo
1Bn1n2N9Z3Xhnxd3b6ViNMstg7oGjh8XAa
1BwrmTmhnp6K6Shbq5zQQqGqnsfXsunsqE
1C4YepY3K1gDrRiQ5E9rgaJuXvrawxXMJG
1CAsRJ5Z9CXdhBwxrCVrf8kJNPBxYQJiH1
1CLfNqGBb949bBbMgefRPkDVgpgyEgWRF
1CPzjQTH5vNADXQGeCfHtRgX8S5xMLGMr4
1Cbw9MZ8Vrfkzv1FxuJS5JBySbypuMARQj
1CgEzXmF7SeNr8rd2AfyN1DQNJpprVxWmW
1CjKefUiRhK5hWf79MoJqccHC1ohye7SWr
1CpV2F9YASreNrBGf1E8QgFgKdqYQopzGH
1CtgapxmS4CRLCNFGTbidAqfk9WNdR2kdn
1D76ha9QoxkUPLxufDoZVEzx6hH3uVJvnZ
1DEsbC42Je7psYeaE2mbWNUpSEFTL9aQUs
1DL21hg5FBLC4h9mXwx9XDbHmUK3BZFCQe
1DkCk3S98BCwPP8wdmxqQKcQoH4WJthvMR
1DpyhFtQs3yVM4gSf3KiD9GBxcPaxuQRDT
1DqXkT8KR25q56sAerfSg875KaJ6o3f3mi
1Dsoi4eggJhipmYZtFGPGBxLX8nguYxiGh
1DxzwX4qC9PsWDSAzuWbJRzEwdGx3n9CJB
1E1rbpZitcZ73JQoLYXB18pDm8BTHVqxtk
1EGok6kAbJRrzryXAGyCHRq5c649rhzwJ3
1EKJUnK4EE83LdGsCnFPZxgkybyFiTdbMk
1EMkFrY86siasW3F9zC2bS1ZcSuTdaiJqj
1EMxjb3667se6LuqkhRsrBaAScGsx5DMFq
1EZtDBBkqkHxRXNSBwTV7HhBbPVvqC8Rte
1EkkAMw1K6HKGiou5vNrLBffDtjVAC5HW3
1EqBqwtfJMZERvyckvexLJLuSrqYewCaE3
1Es37FWCT3xDCrQM2NEJLajRPYNbk7jUaH
1FMhAUpVgU2H3n576vUe7vQp94zCkRPnf6
1FSmh8gSuPkZTqx6LeH6Jic4iZ1A8BsZ2L
1FyQtBr9ub8FhKGDcgW2uAbU6cHYuNmBk3
1GNvTWNZM48QA44QmbVjxXhQ7hmJDicxec
1GvhZ6FewuuyYwZ9cPWd614Gu6UhWacrDY
1HAEJNWN7johTEiooRau7F6NFvHnBDXHzh
1HDGRnafT7ogCaMuHx9csBGvGeYc441tQ4
1HMYjeeZf4qq9L9WZRaBKnNjsP1bSLsuMs
1HSUdtBoNbexP3ordhnSZ2jfHCGVvAbGt
1HW45VWikPEoijyKtguggMEJ5CnsS78ESf
1HfjrpJLP5SaPRFzYUxrzhppw6xv6GXZ6f
1Hu5wfuk9nHuYDpdX6FjQrU1NYvpUS8r6t
1JHL7mbGq64heFnJA8i2QVm18p4TQ1kf9M
1JX7Z9Si6tUQgFa4PLNTtJ8bC9WrfMDvLb
1JmY6KZxoMjMaFKLVSMAr7BdsAAWASMR7d
1K3iZPSqMCxtMd5o5hw4gfpFq3i9zqL61o
1K8fu7jfjuKS28YrA2rSCy7fkZhNvcab5p
1KJERjQwXx8ojrKRSPFKwkCct1aAkyHgnF
1KS7abb8CrqrSizfyPXkcRocYejZQ332xM
1KiAVfFJH9EU29C9H9p2SBnrkfzrgrRRCe
1KojFMcdHzDndhfqPxb5CnXeB1R5u9nnxG
1KpxMLLmEhaqoUXN1hfq8fci4z7p593HsV
1KvvnDBRtHFZdE9ngqGWV5VGznFgXuF1fd
1Kzf3YptWEMwDHF1nmVpMbs3jSvWjWdSbR
1L2Bcohuf1qyHykTdP8rD74K6HQSsTaTE
1LCnNsa2pxbZCsVdRoNqLGFcULbrEFL4i1
1LKVE8ys5rep3LbELC3fhfCRWXQiEi7hpv
1LKumxgbfSycQVaAwagpyZRSy71wXC2zhF
1LWDzisQtETsxk6N8QNa1KuUSiYtmmfa5A
1LhA9wbU4enUCT8EVorxeJegQtkZcyr7m6
1LrUd8tr5TD3UvD4KZaiNcAxmFveCw5h27
1M52izWFApBEuRMqMx4gbr8prABCA9Q9tv
1M7hSnVZniAXrre2SH9qaHvfxgXRAjpMVk
1MLQDQQsaHPSPQwp3TJ5YSbffm2EHneaU9
1MMMpX4AKhf9JTviWuU7fwnZuTdW78G2Mf
1MX1fSzSvTuw3yNgPNE3Ni31kT1DSdeUPC
1MmJk1peLVmycqY8Hq6WyZfrK4u1oTvkER
1NAddQ2XhM96aGn4yK9naRzxTxe7BbNTLG
1NLbWbTczixoA3sCgQg5NLpsExqRPJiA3H
1NMb6g4rQXHmsaHaiy1iV2Wmn4bTGwxyLT
1NR7Bw4XWK3oic9HvgWFProGVzp5jKeqCw
1NWXH2DE5DTfKWAwABAvFesGXKkyKBUoiN
1NeAtszct9Uav81CEr1FGhV4KAaXahdsVF
1NjGEKWWrupvbzvEivnfXJpdNdXK5xzdDb
1NkYPP3Eix9shAvU47xJtnL4Ggd2ScAbcD
1P5anXJVbPeXsw4wExuQ8SCBRevRPe8syQ
1PEAu3bS7t6ZYKGX77ZJsEKSupGzdR5Kpj
1PNa9dZ3P3fVhx1uMCqJ4sEYmyhxnQNy3M
1PQwoVNRCiK2J5GNumfpT3qk7KnhKPJ6Ph
1PVHbRqh1eYsGCVZ7t18UCQ6oPzXFR3HQz
1QBYgXMTqEQNgoVotQN2iP1sPhHRPEoDHb
1QDB2W1VFqinxu5zm4qMGecQTfviBjk3JA
1RfEM5WPtboTNnjHN3HR889FyuUx6T14D
1ZaRiG4qLj336tKFMZCGPpySoRQsReivv
1iuC1ovtbMJQLniEiJtR5obbWvVkmTjiE
1ptDzNsRy3CtGm8bGEfqx58PfGERmXCgs
1sgNrgAnjMVSzyeMDTeVsKN7FuZy34U5t
1vdbVPC6Ts9d5WhRDriPdndvvCwmCbKCj

There was a tx signing bug in BitcoinJs which Counterwallet (a Counterparty web wallet) triggered. Counterwallet has been patched, and all users of Counterwallet should indeed generate new accounts and sweep all of their funds there.

See the original announcement (https://bitcointalk.org/index.php?topic=395761.msg6354587#msg6354587).

For this and other reasons (flawed, weak, unverifiable or backdoored PRNG) developers should strongly consider using RFC6979 to create deterministic signatures.  The k value does not need to be random it only needs to be unknown and used once.  Transactions are already unique and the signer has something which is unknown to the public (private key).  This means it is possible to sign transactions without needing to rely on "random" elements.

http://tools.ietf.org/html/rfc6979

There are implementations in Python, C++, Java, (and when I get a chance to do some refactoring C#).

Or see how it is done in Java:

in Bits of Proof:

https://github.com/bitsofproof/bop-bitcoin-client/blob/master/api/src/main/java/com/bitsofproof/supernode/common/ECKeyPair.java#L157

or in bitcoinj:

https://code.google.com/p/bitcoinj/source/browse/core/src/main/java/com/google/bitcoin/core/ECKey.java#480

We have a victim here (https://bitcointalk.org/index.php?topic=581667.0) with the address 1PNa9dZ3P3fVhx1uMCqJ4sEYmyhxnQNy3M.
It seems he is using blockchain.info wallet.

This is indeed my wallet. I also did use Counterwallet recently to access some XCP that were tied to that address. Early this morning, 12.5038 BTC were stolen from my account, apparently due to this bug with Counterwallet.

Has in the past or is currently brainwallet.org vulnerable to using the same or weak R / k values when building the transactions?  I see bitaddress.org now has an extended random generator on page load, and I believe blockchain.info wallet was patched when the android bug was discovered.

Practically all of the web keygen / signing apps I've audited use a really sketchy structure where access to the system's cryptographically strong prng is inside a try/catch block and failure results in silently replacing the entropy with snake oil...

Interesting to see that this instance was a different failure mode where the inadequate type-safety of JS combined with a lack of testing for deterministic DSA yielded sadness. (It appears to use a derandomized DSA, but had no tests for it, and the ability to test is one of the big advantages of derandomizing DSA... an underlying library change the behavior of the hash function and the signatures started using a constant nonce).

So sad , my address is on the list .

But thanks for the post!

Since this thread was bumped, I think I should update it.

There seems to be a new buggy program that reuses the same R value for all signatures in a transaction.  It started around September 2014. Because the program uses mostly unique addresses, the bug is not always exploitable.  But reuse happened often enough to break over 400 new keys. The list is getting too long to post it here so here are the links:

http://johoe.mooo.com/bitcoin/broken.txt (http://johoe.mooo.com/bitcoin/broken.txt)
http://johoe.mooo.com/bitcoin/endangered.txt (http://johoe.mooo.com/bitcoin/endangered.txt)

The first list contains the addresses whose private key can be computed from the block chain.  The second list additionally contains addresses that were used by the faulty client but only in a context where it cannot be broken (unless I'm missing something).

Does anyone know what the buggy program is?  Or does anyone recognize any of the more recent addresses?

Note that the addresses that appear only in the second list still may be in danger, e.g., if they stem from a BIP32 wallet and one knows the "xpub" public key.

It looks like there are some bots sweeping all funds that go to such a broken wallet.

I asked in your other thread (https://bitcointalk.org/index.php?topic=879419.0), but which program did you use to create this address and where did you get the program?

I'm a little confused with all the tech junks that is being talked about here. Can u plz tell me in simple terms that if I use blockchain.info to create an address, download the paper wallet containing the private key and keep it and the password safe, then am I secured ?

I can see gmaxwell was talking about some try-catch which may kill the entropy in the seed. Is that present in blockchain.info as well ?

If you are asking this question - it means that you are not secured.

So as far as I understood it he used omniwallet.org (http://omniwallet.org)

He said "I  imported the private key of B" but he might meant that he created it there. And then he said "The address is mine, I create it from the wallet!!" which probably meant that he used bitcoin core. I think that either one of them.

Edit: he generated those private keys using the blockchain.info web wallet.

The private key leaked due to the counterparty bug.  The transaction that revealed the private key was
https://blockchain.info/tx/86510ddeded6486b73fe08ab4ce6320ab1aa1d5d006d699e37aeb1b1e9df3e50 (https://blockchain.info/tx/86510ddeded6486b73fe08ab4ce6320ab1aa1d5d006d699e37aeb1b1e9df3e50)
The wallet was already sweeped in April, e.g.,
https://blockchain.info/tx/737326ba838fb6b887480f9be2924141000d5e11e8bc450655ab4743da508754 (https://blockchain.info/tx/737326ba838fb6b887480f9be2924141000d5e11e8bc450655ab4743da508754)
Probably the amount of 0.0017 was to few to be noticed. 

So the moral is, don't reuse your old addresses, especially with different clients.  Otherwise, you will get bitten if one of the client you tried is buggy.  If possible, use a fresh address for every transaction. 

It is hard to test javascript code in every browser and if the entropy generator fails under some systems, usually nobody will notice (until two people create the same private key by accident).  That said, I haven't audited the blockchain code, so I cannot say whether it has this problem or not.

But if you want to generate a paper wallet, because this is the most secure storage, it is a bad idea to do it on a service that stores your private keys in the cloud (even if it stores them encrypted).  If someone guesses your password or phishes it, he will get access to your keys.  If you generate a paper wallet, do this on an offline computer.  The private key should never leave this computer at all (except to the printer).  If you are paranoid, install a fresh system on the computer before and after you generate the paper wallet, to avoid trojans on your computer.

I have a standalone machine with Pentium II processor which I do not use for long. It is infected with some virus/malware too. But I dont plan to connect it to the internet in some coming years too unless I get time to re-install fresh OS on it. So, if I download bitaddress.org in my current machine and copy it to the old machine using an USB and then generate an address over there, just to note down the address/private key pair on a piece of paper, then will that address be safe for use as a cold storage ?

Do not use infected machine for this. Just don't, no matter if you don't plan to connect it to the internet, you may connect it accidentally by mistake. It's much better to boot fresh OS from the CD, for instance many people recommend Puppy Linux (http://puppylinux-woof-ce.github.io/woof-CE/) for this purpose since it works well with many printers and runs almost on any PC including old Pentium II like yours. Why risk something when you can do it safely and don't waist time on OS re-installation?

As said, don't use it. You don't know if the random numbers generated are truly random, they could be predictable or plausibly brute-forceable for the attacker.

You must be joking right? Considering his machine, the virus was probably written 15 years ago or longer. Nevertheless caution is needed.

You implying that it's impossible for it to have gotten a new virus in the last month?

I just noticed that amaclin (https://bitcointalk.org/index.php?topic=879419.msg9706922#msg9706922) tries to double spend the broken transaction in real-time:

https://blockchain.info/tx/df02f56b230c397cb67bb5334209f7e45d58f1f9d6eb1df1bc17e6ecb107e206 (https://blockchain.info/tx/df02f56b230c397cb67bb5334209f7e45d58f1f9d6eb1df1bc17e6ecb107e206)

This is a double spend of the transaction that revealed the private keys.  In this case the double spend was not successful (despite the fact that he used twice the fee).

Since my lists are generated using only the transactions in the block chain, the list won't contain the addresses where the broken transactions were successfully double spent.

A Pentium II machine, which is not connected online for long is supposed to be safe from new viruses. Is not it ?

Nothing is safe. You have to ASSUME compromise and act under that assumption. Nothing wrong with using this machine, but only after a full whipe and clean and you verify no root kits, and not running and old software or some decades old OS etc.. Beyond that, there is NO REASON to connect the system to the internet for ANY time as opposed to 'not long'. If your going the route of an isolated machine for generating keys, I would recommend a livecd version of a linux distro, with a python or shell based tool for address/key generation included on it. No exposure to the internet for the system....

I know.

Would you mind charing it?

Do you mean "share info"? I do now want to do it right now.
Everything is visible enough in the blockchain. Just open your eyes and use your brain.

Why take the risk if you can just start a bootable live cd of some linux distro?

Well, either you keep that information because you have informed the developers of the buggy program that they have to fix it (which would be laudable) or you have other, possible sinister reasons to keep the program's name for yourself.

Which one is it?

He sweeps those addresses for the coins.

I haven't said that I have developers contacts. How can I inform them?

Are you ready to prove it?

I was just reporting what you said here:




See:
https://bitcointalk.org/index.php?topic=879419.20

And other threads where you say you scan for the addresses (like many other people do).

These are only words. This is not a proof.
Let me say here that I am a president of United States.
Do you trust me and my words now?

Hello,

there were a large bunch of new broken addresses today (several 100s in one day).  I took the liberty of saving some funds before they got swiped by others.  If you can convince me that they belong to you (signing a message with the address is obviously not enough; the private key is already known),  I will send the funds back.

Look into the file http://johoe.mooo.com/bitcoin/broken.txt (http://johoe.mooo.com/bitcoin/broken.txt), to see whether your address was broken.

Is it your address 1HuqM18GMVaLxTRGdmSgytzVYnhRzu7U68 ?
And is it your service: http://sharedcoin.com/ ?  ;D

yes
no.  Just plain old bitcoind using rawtransaction interface

I think this is not related to the other bug that started in September.  There are a lot of reused R-values sometimes not even in the same transaction.  The scale is also much bigger (500 addresses in one day, >200 BTC).  I still count almost 300 unspent outputs (but I'm too lazy to swipe them all).

I mean that this service belongs to bc.i
And you are also from bc.i (may be I am wrong of course)


Man-in-the-middle on tor exit node?
or may be http://www.reddit.com/r/Bitcoin/comments/2oltp9/warning_blockchaininfos_javascript_verifier_is/

No, this: http://www.reddit.com/r/Bitcoin/comments/2onm5r/blockchaininfo_security_disclosure/

Thanks, for the link.  Although, if they already fixed this problem this morning, why are there still repeated R values generated? 
I still find reused R values in new transactions.   Is this just a browser cache issue or is the problem still not solved completely?

E.g.:

https://blockchain.info/tx/f10d5c469c634de25276aae9c4e14add80ad9c66000182fac1b30e72a99298fb (https://blockchain.info/tx/f10d5c469c634de25276aae9c4e14add80ad9c66000182fac1b30e72a99298fb)

uses the same R values as:

https://blockchain.info/tx/cf0b65ec6a2f9b5e003358d7b9bb6e04b30138c4dba30724f600bf753bfc3f4a (https://blockchain.info/tx/cf0b65ec6a2f9b5e003358d7b9bb6e04b30138c4dba30724f600bf753bfc3f4a)

Dude you took from my address, I was saving up for my family for christmas and you went and stolen it this morning..

Please have the heart to give it back, PMing you now

One of these address' is mine, can you place contact me, I can provide proof with screen shots or teamview.

I created a little procedure to check if your address is at risk just in case you are using bitcoin-qt.

1. activate "enable coin control features" in options, wallet
2. go to the send tab and click inputs. A list of addresses is shown, sort it by clicking on the heading(the word Addresses)
3. copy/paste each address in this tab to a text file(right click on an address and select copy to put it in the clipboard)
4. save this text file and call it myadrs.txt
5. save the file linked above in the file adr1.txt
6. compare the two files by using the *ux command
    sdiff myadrs.txt adr1.txt | grep -v "|"|grep -v "<"|grep -v ">"
7. if an address is shown(twice), that address of yours is on the list

You can repeat the procedure above for the two files mentioned in https://bitcointalk.org/index.php?topic=581411.msg9711303#msg9711303

If you are running Windows, you can install cygwin to get *ix like commands.

There might be faster procedures to check your addresses, this one worked for me.

Hey johoe,

I'm sure you are aware this was a blockchain.info screwup.  See here http://www.reddit.com/r/Bitcoin/comments/2onm5r/blockchaininfo_security_disclosure/ (http://www.reddit.com/r/Bitcoin/comments/2onm5r/blockchaininfo_security_disclosure/)

If you are willing, as you have stated, please contact blockchain and work with them as they have the info to prove ownership.  I'm certain you would be rewarded.

Perhaps blockchain.info (if people still trusts them) can create new addresses for the affected users, post the old-new map, and the "good samaritan" can then transfer the amounts there.

Bottom line, if this guy didn't do it, then someone else would have.  So the fact he revealed it was him is a good samaritan without quotes in my book.  Your idea has merit, blockchain should contact this person and figure out a way.

I'm pretty sure blockchain will reimburse users, since blockchain is clearly at fault and have admitted to it. Returning the funds won't change whether these people get paid back, although it would help blockchain if you actually care about that fact.

The non-random rng would have also resulted in giving unrelated users the same keys. It didn't just effect signing.

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

wha's wrong with my wallet? how to find back my coin?

The Good Samaritan collected ~216 BTC from some 200--250 compromised Blockchain.info addresses, the last one ~4 hours ago:

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

Are those the only ones? (I saw a claim on reddit, without any evidence, that the total losses were higher. Any source for that?)

i am fucking livid right now. over 3.6 btc stolen from my wallet. password changed and i can't get back in. has anyone else had issues with the passwords being changed ? i don't understand why because the wallet is empty.

if i didnt have my wallet as a watch only" address on my phone this would have gone unnoticed. sent a message to blockchain but no reply yet.

anyone else have this problem ? I'm so distraught and upset, this sucks.

https://blockchain.info/address/18VfH6NCktwZ835z4zp52wmvpWEGCSenuf

my 0.382bitcoin was gone   :-[  that was all of my assets
 
blockchain.info please  Compensation for me   
https://blockchain.info/address/1Ha7DNXbiUi5DozhZjtDDveciamb6uQZbR

Your address seems to be one of those colected by the "Good Samaritan" and moved here
https://blockchain.info/address/1Ha7DNXbiUi5DozhZjtDDveciamb6uQZbR
He promised to give them back as soon as the owners can prove tha they are theirs.
Check previous messages in this thread.

Address:
1Ha7DNXbiUi5DozhZjtDDveciamb6uQZbR

Message  i am tenecntcoin

Signature:
GzTGNPLtIU659u5sVN+s+0HaVfq9gFAaM5dqgpDogTjDAhEQ8f869TrOth1ARjnGcU+w6fC6Og97mpXFbjgC3a4=

please return my bitcoin to the address 1CjDsHkuhsS4AyueugoV5dMWEUd35r9QZM

Oh just noticed that someone else just started to swipe the coins(not me still didn't figured out how to do it) https://blockchain.info/address/15g7xSy7j9vMRc9d6Vgn4ugfn2LiV67eaR (https://blockchain.info/address/15g7xSy7j9vMRc9d6Vgn4ugfn2LiV67eaR) most of the inputs were from the list so I am 100% sure that someone else is wiping the last coins which is at leas another 10BTC.

Guys just contact blockchain.info support in case you haven't received an email from them:
http://blog.blockchain.com/2014/12/08/blockchain-info-security-disclosure/

How do I prove they were mine ? Who is the good samartian, why did he do this ?

You got to figure this out yourself.
johoe is the good Samaritan.
Because he is a very good person which guarded most of the coins from people who would have stolen it.

I don't think that he is a good samaritan unless he eventually gives me the coins he stole back. I also sent an email to blockchain so hopefully I can get refunded or something...this is retarded.

i also have send him pm , i wish my coin come back, that is all my btc

please do not cruel to me  :-[

Here is one BCI user who claims to have lost 99 BTC which were not moved to the Good Samaritan's address:

http://www.reddit.com/r/Bitcoin/comments/2oo72b/victim_100_bitcoins_stolen_from_blockchaininfo/

The destination address got two other inputs; perhaps other ursers?
https://blockchain.info/address/1M77fUCzQrmY8jHRRgpzDVPAK5eQ31bwxZ

http://www.reddit.com/r/Bitcoin/comments/2oonu2/well_i_was_part_of_the_00002/
This is my thread, I can confirm that and I can confirm that the BTC address is mine also.
Please PM me. I lost $650 that I was saving up for a car. I am only 17 man, I really need this money.
https://blockchain.info/address/1NDmX336zK4ntTLDqbpK9dWk8qNB81z2Q6

Here's the explanation how to sign the message, it's for two wallets but the procedure is pretty much the same for all other wallets:

http://support.bitcoin.cz/Knowledgebase/Article/View/36/0/how-to-sign-a-message-using-a-bitcoin-client (http://support.bitcoin.cz/Knowledgebase/Article/View/36/0/how-to-sign-a-message-using-a-bitcoin-client)

Just sign the message to prove you are not trying to steal somebody else's coins, and PM that signature to johoe, he promised to return the coins to their rightful owners. IMHO it is very honorable thing if he fulfills the promise, if he haven't collected the coins a real thief could have done it and you would never see your coins back.

Just to note:

Just sign the previous address from which the funds were transferred from(their outputs)

Good idea. This is definitely proof the coins are yours, no question about it.

Well, that's not the only problem.  Signing a message with the key associated with the address the funds were sent from - and this would of course have to be an unaffected address as well - does work well... if you can do so.  If you are not the owner of that address - e.g. you purchased Bitcoin from a service, you're mining at a pool, any case where the coins were sent to you by a third party - you would be SOL, at least as far as this approach goes.

In the mean time, it looks like blockchain.info is intending to make affected people whole again.  Perhaps some people will effectively double their returns as a result ;)

I am the other user with the adress 1LDpUmrwVKSFyXy2czE423dH8yd4K9R9WW. If the user with the 99BTC will read this. pls write me a messeage.

 

Can someone point me to the actual commit that introduced this bug?

"Improvments to RNG":
https://github.com/blockchain/My-Wallet/commit/98d5a7ca59ef04d06ac6aee468634b12975a0f5c

I suppose that they generated one number with the new code, and it looked random allright.  :P

I just want to say that I contacted the blockchain.info support, but I haven't heard back from them, yet.

To avoid double reimbursement, I want coordinate this with the blockchain.info people.  They should, hopefully, be able to check whether claims are valid or not.  If you lost funds due to this bug, contact the blockchain support, not me.  I cannot answer all PMs regarding this problem.

Just remember, no good deed goes unpunished. Perhaps this should be in a new thread too.

Most of the coins were saved (216BTC) the remeaning ones went to this address https://blockchain.info/address/1xyWYGDStMKVmNH4hivbfhJZa5xWFVWfd (https://blockchain.info/address/1xyWYGDStMKVmNH4hivbfhJZa5xWFVWfd)

Someone claimed to have lost 99 BTC
http://www.reddit.com/r/Bitcoin/comments/2oo72b/victim_100_bitcoins_stolen_from_blockchaininfo/

They ended up here:
https://blockchain.info/address/18MFgZkAqcBLJcQof81xLFzAQ4r4XLS6sn

Only a tiny amount from them ended up at https://blockchain.info/address/1xyWYGDStMKVmNH4hivbfhJZa5xWFVWfd

Is it the unconditional use of Math.random() after the use of the Crypto API (if available), that lead to the bug? Or is there some other problem, I don't see?
Why isn't there a fixing commit, yet?

In my support ticket with them, I mentioned you. Hopefully this may elevate /escalate the priority.

zootreeves added a note an hour ago:

The money has been returned to blockchain.info.  Please write to blockchain support to claim refund.


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

15tXHJCjehqCEL6zRCkGwvuDY6YzZV5sKP
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJUh5AdAAoJEP3NqDUC96SQqH0H/3pTTawCXZWfWAwIoVQPkSYa
DgpioEvHLDHXegfAfXyo8X9vc50kEseQVeZ5FAvoeC3Hy76gNIgEDllP5o6FUXL2
HsEj7qcafY5AxlxMgRRG9p1OcbeJS6mlbZrjB78BD+zrtzZaLFoSAf4+lw3YZHg5
xvA0WyNoHE1Hzg8+pdPbg1PPN6dHT38+PCyqFgYIjkjq07UbxxtyyWs8KIQqSuTe
4XIh0gjd73Wqtxm4CAHtnwy0PA5Pi/lE7v0d6qqF2l86SlxDkT6067asMw9Te0JJ
WgnFM8fePrM8HU980n0xvamae7J71zlFMN2/RYfj2t/pTIEWz25ZI2iVS0MGg14=
=9MGK
-----END PGP SIGNATURE——

PGP key is available from https://blockchain.info/security.txt (https://blockchain.info/security.txt)

http://johoe.mooo.com/bitcoin/trezor-transaction.jpg

https://blockchain.info/tx/ea8fa447d59000843910932a42bf7a28915772d97a006e97714d026b78885754

That's very ethical of you. I hope they gave you a substantial reward.

You sir... are a fucking champion *tips hat*

I posted on reddit that BC.i should hire him and pay him well just to keep his eyes on the Blockchain and look for issues.  He already earned a year's worth of wages I would say.

But perhaps he has no need. ;)  

Nice job johoe!   :)

I hope to expect an announcement that they're hiring this guy as a security consultant.

It is *so* relieving to see some decency around here after many months of disgraceful attitude.

Thank you, johoe, for being generally awesome.

Johoe is now a crypto superhero. I must to bump

I'm impressed.  :o

Mr. Johoe, hats off to you sir.

Johoe is gentlemen.

Will they implement deterministic ecdsa after this incident?

thanks for being very cool :)

Props to you, johoe!!

Common decency is back!

Good guy johoe. Hella props and good fortune to you.

Johoe, both your and blockchain.info's willingness to reimburse is laudable.

However, I hope you make sure blockchain.info really handles this properly. I hope you observe at least your own interest and ask blockchain.info to at least report to you what portion of the money they've used for reimbursements (ideally you should have only reimbursed blockchain.info for proper reimbursements they have already completed and proven to you). For one thing, very often in situations like that some portion would remain unclaimed for whatever reason. If it turns out that there are unclaimed coins after the proper owners have been notified and a long time has passed, those coins would more properly belong to you rather than to blockchain.info.

Blockchain.info should not profit from their own mistake. It would set a bad precedent if that were to happen.

I'm writing this just for the sake of justice and good business practice. I hope you understand.

Classy.

Today Johoe, you restore our faith in humanity.

Nice work!

A classy act

good on you Johoe

Well played sir, well played.

Sir, very good. God bless you.

You Sir is proof that this world is still good place to live.

Hats off to you sir !!!


Regards

You are admirable
thanks for return . i want to know when will bc.info return to user

While I lost 2 BTC with 209 other investors on BTCJam to a scammer it is so refreshing to see a refreshing act. :)

johoe! = Awesome!

 

I'm impressed. With all the new Bitcoin companies sure to come, perhaps being a freelance cryptosecurity hacker might be in your line of work?

johoe the good guy, thank you for being the white hat in this case. you shall have tons of merits when you visit heaven.

Johoe, you are a great man!
 8)

Class act, well done :) Reassuring that there are still very honest people out there

What about this claim, was it confirmed? It does not seem to have been picked up by @johoe.

That address is listed here near the very end: http://johoe.mooo.com/bitcoin/broken.txt

And johoe said that he didn't swipe them all:

So I guess somebody else did... Too bad. But maybe it's another Good Samaritan.

Yeah, somebody else took it:

Johoe, you are heroic!
Thank you.

Ente

Good to see this. Btw is there changetip for bct?

haven't seen this yet, so  ;D THIS IS GENTLEMEN!

Thanks Johoe that you are one of the good guys.

I would have done the same, but not everyone would have.

That was awesome of you johoe :D

Your parents should be proud of you, johoe!

Just quoting this in case anyone is confused about the whole situation. The issues affecting Blockchain.info have nothing to do with Counterwallet, and everything has been fixed there since ages.

Johoe well done!
People like you are a gem. Please accept this small reward from me for being an ethical hacker:

http://satoshilabs.com/wp-content/uploads/2014/12/TrezorMetallicsFEs.jpg

Let me know how to get it to you.

I cannot express my gratitude towards you. Thank you so very much for this. Sort-of a "Faith in Humanity Restored" moment right now.

Do you mind posting a Bitcoin wallet. As soon as I get the coins back from BlockChain.info; I'll be sure to send something.

Thanks! Rep ++ left.

Wow Johoe what a guy.
Fucking hero.

Amazing hero ! I think the bitcoin community need more users like you , great job ;).

Congratulations I bow before your gesture!
Congratulations ....

All white hats off to Johoe  ;D ;D ;D Tip that ChangeTip hat for him on Reddit people.
http://www.reddit.com/r/Bitcoin/comments/2otekd/white_hat_johoe_returns_255_btc_to_blockchaininfo/

We need more people like him/her in this world.

I have been thinking "Bitcoin" has lost the plot, with all the hacks and scamming going around, and then this happens.

It gives me hope in humanity!!

congratulations
!!!

Nicely done.  Good to see positivism within the community. 

Hats off!!

This is awesome. Great example set by U :)


May I ask you that after creating an address, if I check it against these 2 lists and my address is not available among them, then am I safe ?

If not, then what is the way to check the safety of a new address ?

Epic johoe!

I wish there were more like him. We sure need them!

Will johoe post an address so that we, the impressed spectators, can send him a few beers? Also, is blockchain.info rewarding this hero in anyway?

Very honorable move. You truely deserve the respect!



... exactly my thoughts after reading the post. ;)

maybe he/she is satoshi.  8)

People like Johoe  are so rare, i can't believe what happened here...

No affected by this, but just wanted to thank you for being a boss.

Same here.
Very, very honest.

Rare these days.

thanks johoe , i get my btc return 2 hours ago

i am more bileve you are satoshi

Seems so. Either Satoshi or a very very early adopter who has CPU mined coins.

Right thing to do.Thumbs up johoe

He is only an honest guys , great  work *again* johoe  ;).

Honesty seems to be not so common in these days and even less in the BTC world.
What you did is admirable.

You, Sir, surely deserve a positive feedback on your trust page.

Very honourable work there, johoe. Thanks from all :)

I take it that the reused-whatever bug is solved now? Or do we avoid blockchain for now?

Huge respect for doing this. We need more people in the world like you.

MUCH respect man.... ever thought about starting up a coin?  I would buy based on this alone. . .

Hello,

thanks for all the warm words.  I very much appreciated them.

I have to say, I already got a reasonable reward from bc.i.  Also many thanks to the satoshilabs people who offered me a new trezor (could be handy as a backup next time).  If you still want to donate I added one of my bitcoin addresses to the signature.  And if you ever need to store 267 BTC safely for a few days :D, you can get a trezor here (https://buytrezor.com?a=15504cc10984).

To answer some of the questions:

In principle, it should be safe to use blockchain again, but I still see some bad transactions.  The last occurred six hours ago. There are only very few now and the guess is that this is because of browser cache issues.  So clear your browser cache and reload the blockchain page.  

If you generated a new address on blockchain in the night from Dec. 7/8 (UTC) before the bug was fixed, you should consider this as broken.  
Even if it is not on my list.  The same holds for every address you sent money from during that period using the blockchain service.  If you accessed the website during that period, you may have gotten the buggy script in your browser cache, so you may still be affected if you later created a new address or sent money.  I'm not sure of the end of the time window.  The first buggy transaction occured Dec. 7 21:53:26 UTC (https://blockchain.info/de/tx-index/71309145).  

If you lost money during the last days you can reclaim it by writing to the blockchain support.  They can see whether your claim is valid and will refund you.  That said, I'm not affiliated with blockchain.info  (I just returned them their money).

For the record, I used these addresses:

1HuqM18GMVaLxTRGdmSgytzVYnhRzu7U68
1L7gfUxCY5bDmzp1xA6CjA3qXZwsbzWGbG
1HdqdZudnV681xapavSJp3LqaCcJn12eSE
1EjXAe3WRqipdQdP5qeESjZRhxLVfe6cJ7
17TifxwuGSor7woQ64gL57KJzwPAjSf3Qa

the money to these addresses have been returned.

I see that there are several different 1xy... addresses related with this incident.  These are not mine.

I hope that all remaining issues will be resolved soon.

A "thank you" from me too. You saved about 3 BTC of my users' money (I hope blockchain.info will return it).

Very noble of you, sir.

You very much earned them!

Thanks again for you honesty and the work you put in to protect people from theft.

Very cool of you, didn't lose any funds but its refreshing to see this sort of thing.

Do you think the majority of the reused "R' values issue has been resolved? If so could you explain how you were able to identify which addresses had the reused R value and how to calculate the private key from the public key?

(maybe you could delay releasing such information until after the flawed transactions slow down a little bit more)

This information is public from 2010, since the Sony PlayStation fiasco where they used R=4 to sign *all* the games in their online store. At the bottom of this article http://kakaroto.homelinux.net/2012/01/how-the-ecdsa-algorithm-works/ (http://kakaroto.homelinux.net/2012/01/how-the-ecdsa-algorithm-works/) you have two simple formulas how to calculate the private key from two reused R values. johoe monitored the blockchain to find repeating R values, they are public in every transaction.

Edit:
To be technically precise, R is the point on the curve you get as R=k*G, k being the random number and G being the reference point. Sony used k=4 as a random number.

It was known right from the beginning, when ElGamal published his signature scheme, on which Schnorr signatures are based, on which classical DSA is based, on which ECDSA is based.


From his 1985 paper (http://thiagogenez-tcc.googlecode.com/svn/trunk/article/IEEE/elGamal.pdf):

And should have been obvious to anyone who has implemented the cryptosystem too,  if k didn't have to be secret/unique you could just make it a parameter of the system and eliminate r and halve the size of the signatures.

You mean that 4 is not a random number?  It looks quite random to me.

More than 9 (http://search.dilbert.com/comic/Random%209), for sure...

Well, it was chosen by fair dice roll.  guaranteed to be random.

No, thank you. This could've been another black mark on Bitcoin to the people outside, but thanks to you it remained quiet, so much so even a lot on this forum is unaware.

Saying that I am now wary of Blockchain.info and probably will not trust it anymore.

A reused R value is easily identified.  Just go through the blockchain data extract the r values (the first part of the signature), put them into a set and, if it was already in this set before, print it out.  You need a set with more than 100 million elements, but this is technically not so difficult to manage.

I have two lists of addresses, broken (http://johoe.mooo.com/bitcoin/broken.txt) and endangered (http://johoe.mooo.com/bitcoin/endangered.txt), the latter contains all addresses that were used in connection with an reused R value or are equal to an R value (R is very similar to a public key).  The money of the broken list is now swiped except for some dust; less than 10 mBTC in total.  But there is still some money in the addresses of the endangered list.  Nonetheless, these addresses should be considered compromised and I think with a bit of brute force it should be possible to break them.   At least these users should have been warned by now, since blockchain also has these lists.

I detectected a bit more than 1500 transactions with reused R values since Dec.7 (some of them are related to another problem that is going on since September). My guess is that statistically there should be about 500 additional transactions with a weak R value, where the R value was never reused; but this is pure guesswork.   These should also be considered compromised, but I have no way to detect them, so the users cannot be warned directly. Also newly generated keys should be considered compromised, even if they had no transactions at all.  So if you used blockchain in that time-window consider yourself affected even if you are not in one of my lists.

@johoe: Did you use the blockchainr tool or make your own?

Hey, Johoe

I wasn't affected, but I just wanted to say thanks for being such an honest member of the global Bitcoin community.

It's such a welcome and refreshing piece of news.

If you ever need any help with anything, PM and I'll see if I can do anything to help or put you in contact with someone who might be able to help - with anything.

You look good in a white hat ;)  Sincere thanks for discovering this and seeing it through!

What does "weak" mean in this context? I'm also wondering about the "endangered" list: since they already moved coins, I would assume they are now "secured", or is this a flawed assumption? This thread becomes more and more interesting, thanks for your input.

/tip 250000 bits ;)

Hi, johoe.

You are really a hero. Nice job!

Since the day before yesterday, Bitcoin users in China asked our team about blockchain.info's problem.
So we started digging into the issue and found out:
It was not only the repeated-R, and there were more users affected by this event.

Some bitcoins on these vulnerable addresses that we found were collected to here: 1PGfLgFtRHgdgvPNvmHMjtsWwF4fyG1jvh

Currently we are continuing to evaluate the consequences.
After we finish all analysis, we will post more details here and try to return these bitcoins to correct users.

Wen Hao
Bither Team

It means that the k value used might be predictable due to the bad RNG. If someone can guess the k used in a transaction, then the private key can be recovered.

I lost 23800 safecoin linked to my btc address , who would take the responsibility?  XCP or blockchain.info?

How about you?   No one but you chose to use counterparty or blockchain.info.  I'm sorry to hear about your loss, but this is what happens when you use unreviewed cryptographic software-- especially things which have already been publicly criticized and have even suffered similar failures in their past.

How many places are you planning to post this?

https://bitcointalk.org/index.php?topic=879419.msg9825935#msg9825935

Great.
A have to add:
No one but you chose to use crypto-currency instead of national money.
You pay nothing to community - you have nothing back from it. Point.
This is law of conservation. Even Satoshi Nakamoto can not break it.

Just two threads.

I think the two threads are relatively.

Sorry ,I do not understand your logic.

I invested the safecoin at 2014.4.22. https://blockchain.info/zh-cn/tx/917c77c3e6953c4d96ab9627fc809bd3731d7093cbfc3d1074b1ff23bdd90682

and the problem exposed at 2014.4.23.https://bitcointalk.org/index.php?topic=581411.msg6354731#msg6354731

How could I know thing happened in the future?

could you tell me the price of BTC 2016.1.1?

could you ?

I am a victim here, all right?

I can. Less than $10. Wanna bet?
But discussing price / loses / investing / risk / insurance / obligations is offtopic here.

UPD: sorry, i do not understand chinese.

zing

@bcearl: I used my own tools.  Basically finds repeated R values as I have written before.

@lifeisgreat88088: Definitely not bc.i.  Your address 1CAsR... was exposed in April by the counterparty bug.  They refunded the users back then.  You probably can still claim the 0.0017228 BTC you lost in April (doesn't help you much I fear), but I doubt it extends to the new money you put on the address afterwards. 
 
@dexX7: I received it, thanks.  Weak R values = values produced by the broken RNG.  I never looked into the RNG. I only looked at the random numbers random people produced when signing transactions.  Assuming there were about 2000 signature affected by that bug, I only see a weak R value if it was produced twice in these 2000 signatures (otherwise I see it only once and assume that it is not special).  Note that not only the k/R values (k is the private key for the public R) are generated by the RNG but also new private/public keys.  I only did a very basic search for them but there are 83 public keys that match an R value.

My estimate on how many weak R values I don't see is based on the distribution of R values I see 2, 3, 4 or more times.  This should give a geometric series from which the number of weak R values seen only once can be estimated. The data basis is too small to give precise results.  I would say from 300-700 such transactions should exists.

We want to see Johoe as the chairmain of  bitcoin foundation !

I know there was another 3 pages of people saying thanks, but I want to do it too. Thank you.
Also now that there is no coins in those addresses, how did you got the private keys of those addresses? Lets for example use this https://blockchain.info/address/19owWJcPbTEe1mVYer1ymnbduJDza9jpRH (https://blockchain.info/address/19owWJcPbTEe1mVYer1ymnbduJDza9jpRH) There is only one sending tx https://blockchain.info/tx/f10d5c469c634de25276aae9c4e14add80ad9c66000182fac1b30e72a99298fb (https://blockchain.info/tx/f10d5c469c634de25276aae9c4e14add80ad9c66000182fac1b30e72a99298fb)
The R is R=6bcc247f1259262b4035bfa84f0397a69f69baa01659daaf94fe1164b650c86a
The S is S=a044b38e8264a1c928ddd28b4657aa7109d1ea30e911208c7ce57abcb1451fe6
The spending from 1FRD...... https://blockchain.info/tx/cf0b65ec6a2f9b5e003358d7b9bb6e04b30138c4dba30724f600bf753bfc3f4a (https://blockchain.info/tx/cf0b65ec6a2f9b5e003358d7b9bb6e04b30138c4dba30724f600bf753bfc3f4a) uses the same R but if I don't know the private key of 1FRDgmxVrUUNiiB7GN3NNcJDEEXtFB22rm I don't know the private key of 19owWJcPbTEe1mVYer1ymnbduJDza9jpRH
So how did you done it how did you got the private key of 19owWJcPbTEe1mVYer1ymnbduJDza9jpRH?

but there is already that smart guy:

http://graphics8.nytimes.com/images/2014/03/05/business/dealbook/dbpix-karpeles/dbpix-karpeles-tmagArticle.jpg



(PS: nice job johoe)

At least a consultant.

I assume any address which was not created nor did any transaction during that window should be fine?

This is a typical example.  It was broken in several steps:

1LT8zYr6WW5zcnWiYr5gbLT621rPhPGyP2  has two signatures with R-value 2a6f8c926...
This gives us the corresponding k value.
Using this k value, we can now break 1NaMT8A9FysDGRXEL1YdY6VCJUwvXEUedz that uses the same R value.
This key has another signature with R value 460ba0d.... so we can compute the k value for this.
Using this k value, we can break 1Ep4E6WF6jZRhnLCBrFF96fQ8ocvNX728C,
Similarly we get the k value for R value f3b5c9...., that is used with the 1Ep4 key.
This gives us the private key for 1FRDgmxVrUUNiiB7GN3NNcJDEEXtFB22rm.
Finally this has a signature with the R value 6bcc247f1... that was also used to sign with 19owWJc.

Many keys require this multi-step reasoning.  This is probably why the bots couldn't break the keys.  My tool follows these chains.  I think this is why I was the first who could swipe the keys despite doing it manually.

This is the chain my program chooses now.  I'm not sure if all these signatures were present when I broke the key the first time.  But there are other chains leading to this key.  I shouldn't say may program chooses chains.  It just computes K values and private keys until it cannot compute any new K value or private key.

Well, I bet it won't take long for bots to adjust to this tactic.

Was reading through some articles and came upon this
Good job Johoe you have my respect
I tip my hat to you

@johoe: I bet you could swipe even more addresses, if you analyze the weak random generator and try all possible values of k. This way you would even swipe those who used k only once.

Seems to me that johoe can do that nobody else can on this planet.
https://blockchain.info/address/1HuqM18GMVaLxTRGdmSgytzVYnhRzu7U68
awesome!
(he just saved/swept more ~300 btc)

  ;D

the answer is in the post directly above yours (by bcearl).

I am looking at the addresses from which the coins were swept and I am trying to get the priv key of those addresses but I fail over and over again.

I only can say for myself: it was too hard for me to reproduce this RNG.
I found sources http://code.google.com/p/srp-js/source/browse/trunk/javascript/prng4.js?r=12
But I do not know how Math.random works in java-script
By the way. The implementation for Math.random can be different in browsers

I may give more details on the rng later.  At the moment there is still too much money lying around.

Does anyone know how to check if there is an unconfirmed transaction trying to spend an output?
Do I have to use bitcoin-cli listtransactions and then dump each transaction to check which output was spent?

The wallet operations on bitcoind are so slow when you have 1400 private keys imported.

I hate that signtransaction or sendtransaction don't tell me which input it is that I shouldn't spend ::).

Is it safe to send BTC from a blockchain.info wallet to another wallet or cold storage yet?

I'm hesitant to make any transactions on there now.

Am I safer just leaving what I have left there where it is for the moment?

Were R values re-used again today? I see that johoe has ~250 BTC more in his wallet today with messages saying "Contact Blockchain support".

As far as I understand they are from a previous bug of blockchain.info but this time johoe uses all possible values of k.

Yes it is safe to transfer all of the funds from your blockchain.info account to a newly created wallet with bitcoin core and never use that blockchain.info wallet again.

Can I send my entire blockchain wallet to a paper wallet without it being compromised, at least on the blockchain.info end?

If you mean "Can I send my whole balance from blockchain.info to a paper wallet that is not created by blockchain.info" Than yes it is pretty safe if you generated that paper wallet in an offline mode.But after that never use that blockchain.info wallet.

No such tool exists.
Even your node has not unconfirmed output you can not be sure that all your peers do not have such txs in their mempools.
Note: you also can not spend coinbase outputs from Eligius before 100 confirmations

Thanks boss

this is wild man

Okay, most is swept, I think less than a 1 BTC remaining :)

I can assure you that there were no massive new weak signatures appearing.   Instead I managed to analyze the broken RNG and produced the same "random" numbers again.  This enabled me to break most of the keys that were exposed last week.  I can break a key, even if the corresponding R value appeared only once in a signature, because my simulated RNG provides the k value.

As always I plan to return it to bc.i and you can contact their support to get your refund.

Thus far I generated 51200 random numbers.  I should check if I find more keys when generating more random numbers.

Just write a program with Javascript that prints out some k (and corresponding points R) and save them. I was just too lazy to do all that, I hope that my posting did not inspire some thief. I thought that if I post it maybe another good guy will do it before. Anyways everybody who used the wallet in the time it was broken should have known and sent their coins to new addresses already.

If you know k, you can compute the private key. Known k is even simpler than with two unknown reused values of k.



(If I saved your BTC, you're welcome. 1PMh3K3QrKwaKhmjH46ZqniHwHJvwW3xA)

You are really someone in my personal hall of fame man.
Even if I don't keep a penny on b.I. I feel bad for them and for their customers and I know that many horrible things may happen in the future also to others and it is very good to know someone like you is around.

This bet open to anyone?

Wrong this address alone holds 1.6BTC https://blockchain.info/address/1JLiqe4sbD2Qfj1cnmaPDiaxAjQTVBXaMk (https://blockchain.info/address/1JLiqe4sbD2Qfj1cnmaPDiaxAjQTVBXaMk)
This one has 0.15BTC https://blockchain.info/address/1Lp5FEqQf5dHeZyJpoB46gxMUqpbVtepBN (https://blockchain.info/address/1Lp5FEqQf5dHeZyJpoB46gxMUqpbVtepBN)
This one has 1.15BTC https://blockchain.info/address/1HYw2qecuFCL1CdXt1eShPF9fyUdXLUfBW (https://blockchain.info/address/1HYw2qecuFCL1CdXt1eShPF9fyUdXLUfBW)
This one has 0.28BTC https://blockchain.info/address/1MY5sbAmgQyhZ5cAeqkiREnGdqvf7MbwfT (https://blockchain.info/address/1MY5sbAmgQyhZ5cAeqkiREnGdqvf7MbwfT)

Maybe they don't have weak k?

As I understand there's a new feature which will be introduced into bitcoind 0.10.0 to work with addresses without importing private keys (watch-only):
https://github.com/bitcoin/bitcoin/pull/4045 (https://github.com/bitcoin/bitcoin/pull/4045)
It should give you what you want with 'listtransactions', and should be working already in 0.10 branch in github, if you feel like working with it.

I am glad that you could rescue them. I was too lazy to do all the coding, and I haven't started at all yet. :)

Well he already swiped from those addresses once but he left some so he will probably swipe the remeaning ones
I still don't really understand how to do it by hand not taking about the coding.

I feel like Sisyphos.  You think you swiped everything but in the mean time someone else sends you new money...

Reddit talking about johoe today.

http://www.reddit.com/r/Bitcoin/comments/2p9zv2/300_more_btc_swept_from_insecure_wallets_by_johoe/

You need Bitcoin forwarder service, upload private keys and it forwards funds the moment it sees them on the blockchain. Since it doesn't exist, you'll have to write your own ;)

Keep rollin' that big Bitcoin up that hill, brother. We have need of you up there ;)

Another 500 keys cracked  ;D

I have computed more random values, but still have not captured all.
Unfortunately my ssh session timed out and took my script with it  >:(
Have to run it again, it will probably find some more keys.

You, sir, are a true hero! Thanks for saving the day again.

What surprises me is that no hacker tried to use this in the meantime to steal.

Ok this for help us continue  :-*
we be wait more your details and informations   ::)


P.S

You very popular in tv show
guy robin hod
make 200.000$ victms you big boy in bitcoins scene

also thanx for any your donations we accept in our scene litle more
i am very love you!

This is going on and on with no end in sight :o

Keep up the good work, johoe.

I think it'd be a good idea not to explain in any detail no matter how minor the process that allows you to get these private keys etc.

People with different intentions are going to learn how to do it.

If there was a forwarding option in the protocol, the first thing a black hat hacker would do is to sweep the coins, the second thing would be to set up forwarding to his address (and set it again every time the original owner tries to reset it).

I'm confused here.

I have been using the reference (Satoshi) client, both the graphic version and the daemon version.  I did not check before posting, but I am pretty sure that I have used watch only addresses for a year or two.

I've had 1+btc "sweeped" into your account, and have requested to get it returned from Blockchain.info - this is their response:
    

This looks like the stupidest idea ever to me - to send them my identifier and password over email (I have other bitcoin in other wallets inside that account... not for long..)

I'm pretty shocked that this is their approach to helping me to SECURE my bitcoin? Is this even allowed / legit?

Are you sure this was sent by blockchain.info not some other scammer?

I guess you'd move your funds away from all other addresses generated in this wallet first. You will have to abandon this account anyway.

If you're still afraid of signing transactions with blockchain.info, you may sign these transactions offline with other clients like Electrum.

@johoe,

I'll send you one of my brass coins (unloaded) to you for free.

PM me or email me your shipping information and I'll send it your way.

smoothie@lealana.com

thanks for being honest! It is refreshing to have that around here.  :)

True. A fix needs to be implemented soon so that other malicious bystanders do not gain access to his method(s) and wreak havoc.

Johoe, you just swept my keys!!!

Thank god your doing the right thing, you are my f*cking hero.

(will PM my address for further verification)

try 'screen' command (gnu screen)

keeps your shit running even if you connection goes down. You can connect again with 'screen -x'

Yes he swept mine too and just emailed blockchain about it.  But yes Johoe is a great guy...tough to find those in this world most of the time.

Then try mosh. Your connection won't go down. Even if your IP changes.

Can you rephrase your questions and tell me what you intend to do and then how you do it right now?

Let's skip the part about how you get the information about endangered coins, but I assume you have a list of endangered outputs and you are looking for a handy way to check, if they are already spent. Is that correct?

You may use:


It returns something, if an output is unspent and nothing or empty otherwise. It can only be used to test, if an output is unspent, but not, if an output is spent. Out of range values, invalid transaction hashes, ... are accepted input and result in "nothing" as well. As per default unconfirmed transactions are checked.

Checking an unspent output on mainnet:


Checking a spent output on mainnet:


This transaction is few thousand blocks deep, but it should also work for in-mempool transactions.

How do you sweep coins? What do you need to be more efficient? Do you have, besides a list of endangered transactions as I assume, also the associated private keys? Would it help to have a script to autosweep coins based on a list of transactions and private keys?

I basically have a list of private keys.   I also imported them in bitcoind.  However without rescanning the wallet (this takes several hours now).

I have my own script that scans the block chain and searches for transactions paying to any of these keys (it also detects multisigs and p2sh but not p2sh to multisigs).  If it finds a transaction spending the output it removes it.  In the end I have a list of UTXO for all private keys.  However, this is based on the confirmed transactions only.

What I then do is to get the 10 or 20 most valuable UTXOs and build a transaction for them.  I sign it and send it to the network.  The problem is that sometimes this doesn't work.  Possible causes:

• one of the inputs is already spent by an unconfirmed transaction
• one of the inputs is a coinbase output and doesn't have 100 confirmations.

I mark coinbase outputs in my list so I can avoid them.  However the spent transactions are not so easy to avoid.  The effect can be that signing return "incomplete" or sending gives a strange error message.  In either case I don't know which input the culprit is.  Usually I have to check each input manually to see if there is an unconfirmed spent on it.


I have to try if it works if the wallet was not rescanned.  If yes, this may be what  I need.

I think what I need is to make this fully automatic.  Take the list of all UTXOs, decide which ones can be spend and then spend them all in one or two larger transactions.  Of course, spent outputs by unconfirmed transactions are not well-defined and may differ from node to node.

The other question is how far should I spend the dust?  If the transaction fee goes to 90 % it does not really matter that we saved the money.  On the other hand, letting them lay around in the block chain for all eternity doesn't help either.  One could also try to suck them in with some high-priority free transactions.

Other people are going to start sweeping wallets.

This thread is pretty much a step to step guide on how to do it now.

 ::)

This has been done before, and it is obvious how to do it. It still requires a lot of skill and work to execute and you have to find the weak addresses in the first place.

EDIT: And by the way: Any wallet service which does not implement RFC6979 soon, is doomed anyway. This kind of bugs will always come up, especially if you run the crypto in a web browser.

It should work fine for any unspent output.


Redeeming dust is always to prefer imho. I guess you were referring to the case where, say for example, there is an output close to the dust threshold, which you could move once, but then there would be not enough coins left to move them again, if it were a single transaction where the fee is subtracted from the dust. In this case I'd try to bundle them. It's usually also possible to get away with somewhat lower-than-usual fees at the cost of a moderate confirmation delay. In fact, last time I checked (https://groups.google.com/a/mastercoin.org/d/msg/dev/h70x_zZKENw/x1cY7F3gh1cJ), about three months ago, the average confirmation delay of a sample of 2170 transactions with a size of about ~600+ byte each, with an attached fee of only 0.00001 BTC, was only 20:15 minutes.

What OS are you using?


I was thinking something similar, but on the other hand: once it was "out" that there are some transactions which can be sweeped, it was already too late, so to speak. And not only once it was mentioned people are doing this already. If I had to decide between trying to keep all this secret or a public database of endangered transactions, I'd choose the later - for the sake of awareness. Imho it is a bit similar to the chaos related to transaction malleability, which was "known for ages", but it still required a major incident to raise enough awareness to make users and service providers start to care about on a broader level.

Try using screen:

screen -dmS sessionname to start a new session (disconnected)
screen -ls to list sessions
screen -r id to reconnect
ctrl+a d to disconnect
exit to ...exit!

If your connection craps out the screen will keep alive. You can even start a session on one PC then disconnect and reconnect to it from another.

I omitted most of the important details of how to do the attack (e.g. how the RNG works, how you get the private key) and don't publish my scripts, so this step by step instruction won't help much  ;D

I have a list of the first million public keys/R values the random number generator can generate.  I think I have spotted every weak transaction now.  If someone is interested to host a 50 MB file (100 MB uncompressed), I can publish it. I also have the corresponding private keys / k values, but I want to keep those secret for now.   The R value list may be useful to check if I found all compromised addresses.

There are still weak transactions. Please, clear your browser cache.

http://btc.blockr.io/tx/info/afcb94f22ceee047fc2b59a55b452e5f9e2bcd697fa2a4056d5ac176020a960c (http://btc.blockr.io/tx/info/afcb94f22ceee047fc2b59a55b452e5f9e2bcd697fa2a4056d5ac176020a960c)
http://btc.blockr.io/tx/info/549cf7a5a11e7a50ccc634f2edcbcbcbc244a4a42de9f946d3c6a32ced27e6f2 (http://btc.blockr.io/tx/info/549cf7a5a11e7a50ccc634f2edcbcbcbc244a4a42de9f946d3c6a32ced27e6f2)
http://btc.blockr.io/tx/info/3f79c9b06d46fbbc3ba6c3fdd0512beeb2e928818cdb7d83035b2575458f55ae (http://btc.blockr.io/tx/info/3f79c9b06d46fbbc3ba6c3fdd0512beeb2e928818cdb7d83035b2575458f55ae)

And there are some recent transactions paying to a weak key.



At last, regarding the pronunciation of my nick (since someone asked):  In IPA it is ['joːhø].  It sounds something like English yo-ho.

50MB and not GB? That is not so much just upload it here https://www.sendspace.com/ (https://www.sendspace.com/) The max you can upload there is 300MB so a 50MB file is good.

Or he can put the file on  www.ge.tt  , I think the max storage (if he register to the site) is 2 GB .

or he can try this solidfiles (https://www.solidfiles.com/) the max : 50 GB storage

Johoe,

Blockchain still hasn't given back my 50 BTC  :'(

Please, PLEASE bring their attention to ticket #32230

You are lucky that the funds were returned at all - now you expect that he should be working for you to get back your funds from blockchain.info (for nothing)?

Sheesh!

I suggest you don't hassle him and you instead hassle blockchain.info who are the obvious problem in all of this (as clearly they did not even bother testing their wallet changes which is why this fiasco has happened).

Trust me, I've been hassling blockchain a lot harder.

This is my life on the line  :'(

It is irrelevant whether or not you think your life is on the line (for 50 BTC you should never have stored in an online wallet in the first place).

The OP does not work for blockchain.info nor have access to their DB - so what exactly do you think he can do for you now?

You have a point, but can you really fault me for atleast trying?

I understand your a legendary user, just go abit easy on me, going thru a really hard time right now.

If you don't want to rely on others, run your own client at home. You should not store that huge amounts in a web service in the first place. And after Blockchain.info told you about the RNG bug (a WEEK ago), you should have transferred them to a new address.

The legendary stuff is not important - and I'm not trying to bully you - I just think it is wrong for you to be hassling the OP who has done nothing but try and help people who have been the victim of blockchain.info's incredible incompetence.

You need to calm down and sort your situation out with blockchain.info as they are the only ones that can refund you the BTC. As much as it might be hard right now being patient is going to help you more than not being patient is.

I responded to your open ticket, but I wanted to let you know that we're ready to refund you. Please confirm the information in the ticket so we can proceed. Thanks!

(Please do not PM me here - all support issues should be handled through blockchain.zendesk.com)

Mandrik,

Thanks a lot for your quick response!  :)

hi my 4.96337825 BTC was stolen from 1A2cs4h2K5wW5eK4eVTxbozuj8z5jBgDKV
sorry for my English, i'm from the Ukraine and it's a lot of money, i worked on it for 2 years
on 1st december it was stolen, how can i receive my bitcoin if it were you? thank you
or send it to the same address, i've changed the pass

https://blockchain.info/ru/address/1A2cs4h2K5wW5eK4eVTxbozuj8z5jBgDKV

https://blockchain.zendesk.com

Thanks!

this is turning into a cluster fuck

Do NOT use the same address again, password does not secure it. Make completely new addresses!

You can even share a screen between multiple connections

Definitely do not reuse that address.  Even if you have changed the password, the key is public so it is not safe, the password will not help.

Yes , he should change the address because the other private key is compromised forever. I think this kind of people must learn more about bitcoin before start own it.

Are you sure this is incredible incompetence? The transactions are no reusing the same R values but there are an (unknown) patterm instead. That cannot be incompetence nor accident, it has to be programmed as it is in bc.i by developers (very talented developers indeed).

it doesnt matter now :( :( :(

it does matter because bc.i is THE site/wallet now and users without a technical background use theirs services so, if they introduced this hidden pattern in the R values then we (all) are in troubles. Bitcoin doesn't need another MtGox's incident like .

I know this pattern and I know how it was "programmed in".  It was a bug: one variable was not initialized.

It's bad that this was not caught before it went into production.  Testing a random number generator is of course hard.  How can you see whether a random number is really random.  One needs to restart the program several times to get a collision.  In this case a unit test or some additional debugging outputs checking that the changed code behaves correctly would have helped, though. The javascript code is sometimes a bit messy and the fact that javascript has no type-checking makes such problems harder to avoid.

You can also ask, who profits?   This incident has given bc.i bad publicity, a lot of work to handle support request, and some bitcoins have been stolen.  Of course, I profited from this a lot - but I'm sure bc.i doesn't think I caused it.

PS: I'm still seeing week R values in some transactions!  Most are okay, but someone is still using the bad RNG.

You are right, but this one was so bad that people got the same k several times. They should have detected.


But yes, it was a bug. Patters are totally normal. It does not require skill to write a program with an output following a pattern. The hard task is to write a random generator that does NOT follow a pattern.

It is incompetence to have a software updating protocol that lets such a bug go through.   The random number generator is one of the absolutely critical parts of the bitcoin protocol and (as you notice) very hard to debug by testing.  A change in that code (or in any part of the code, actually) should have been reviewed with extreme care by many competent eyes before being put in production.


There may not have been malice by the Blockchain.info management, but maybe there was malice by some programmer who had access to the code and intended to sweep the affected addresses once they had enough bitcoins in them .  While the bug looks just like an accidental omission, that appearance may be intentional too.

And the 500+ BTC johoe swept was not enough for that mythical in-house programmer, he was waiting for more hoping nobody will notice reused R values on the blockchain? What you are saying makes no sense, let alone it is impossible because every commit to the code is tracked on the GitHub and such a criminal programmer would be caught. There was no malice from the Blockchain.info side. Just look at the bug, uninitiated variable used as array index failing that array to empty without throwing an exception, it looks like a bug.

No.
Have a look here: http://www.reddit.com/r/Bitcoin/comments/2oltp9/warning_blockchaininfos_javascript_verifier_is/

BC.I put the bogus sources from their local base, not from github.
Later they fixed bugs and commited this to github.
So, code with bug did not ever present on github.

The bug was caught after a few hours, perhaps he did not have enough time to get home and start sweeping. 

Why would a thief settle for 500 BTC if he could wait a day and sweep 5'000 or more.

There was a claim of 100 BTC being swept by someone else than @johoe.  A thief would avoid sweeping small amounts since the more people affected the greater the risk of the attack being discovered and blocked.

A malicious programmer would have tried to make the bug look like an accidental error, to excuse himself.

The programmer who did the commit was innocent, but a malicious colleague or hacker broke into his computer and removed the initialization statement without him noticing.

There are many possibilities...  but I admit: as Napoleon said, never attribute to malice what can be satisfactorily explained by incompetence...

This bug is visible in blockchain since september.
Somebody sometimes sent his btc to btc-e through sharedcoin (for anonymity transfers?).
(it is very easy to track all transfers to btc-e - I can tell you how to do it)

I think that it was one of the developers of bc.i used bogus environment.

Well they almost certainly used Git with their local codebase, so if that can't be tracked on GitHub, can be tracked on their local Git. Chances not knowing who committed the patch with omitted variable initialization is almost non-existent.



Doing this in corporate environment without being noticed and investigated after - do you really think anyone can try this in security sensitive office environment and not ending indicted with criminal offense? If something like that happens inside an office nobody continues to work until the situation is investigated to the end.

Is that so? I thought that the earlier occurrences in the blockchain were due to some other project (Counterparty?), not BCI.

Counterparty bug was in April.
This bug (as noticed johoe) appeared first time in september.
I haven't checked it, but can check my data.
As I said above - this bug appeared when somebody sent btc to exchange with mixing them through bc.i "sharedcoin" engine

upd:
johoe continues to sweep
1723624c2809b62e9a6f11283c9681a1ed0828ca902518dd102509c48a87be7d:0 to 1HuqM18GMVaLxTRGdmSgytzVYnhRzu7U68 [4.89755711]
on my radars right now

The bug that is present since September is different.  It is still going on and I can distinguish it from bc.i clearly.

If someone would have done it intentionally he would have swept the 590 BTC that I found this week-end.

I will hopefully be able to sweep the last addresses in a few hours.

But someone else is sweeping; I'm not the only one who broke the RNG.
https://blockchain.info/address/1MKSWH9pShsLdV54cRLDQ9JKarsjXK4ms5

Or did just someone read the security alert and saved his money?

I do not think malice is likely, but I won't exclude it either.  There may be several reasons why a malicious programmer failed to sweep those coins. E. g. after the bug was discovered, he may have been afraid of being caught (especially if he is some BCI staff, hence a natural suspect, hence with his internet connections under watch).

Is it wrong to think of Johoe somewhat as a hero to the BTC community?

This clearly makes more sense to me since all the work of re-engineering the RNG is not worth the few satoshis left. You did a good job saving the big share.

BTW., if someone with skill would manipulate the RNG intentionally, he would do it this way:

https://bitcointalk.org/index.php?topic=883793.0
https://www2.informatik.hu-berlin.de/~verbuech/klepto-ecdsa/
http://www.reddit.com/r/Bitcoin/comments/2p2kcd/how_perfect_offline_wallets_can_still_leak/

... aaaaaand if skull not enough, he will fail with the error in his javascript, which gives security hole to "Joe Who" instead of himself.

(just wondering about dates. on the December,5 this was published
on December,8 - bc.i failed
in my country we have a proverb: "at catcher the animal runs")

Wow...

Understandably, harware wallet manufacturers tend to present their products as 100% safe, and hide or dismiss their risks.  But, at the very least, you must trust the manufacturer (and trust that they didn't hire that programmer that BCI just fired  ;D), as well as all the people who may have access to it along the path from the factory to your pocket.  As customers grow confident in such devices, the payoff for an attack via malicious fake devices could be huge, and criminals may invest proportionally in carrying out the attack.

I have not made an uninitialised variable mistake in over 10 years (and I code in C++ where this can be a serious issue).

For code to have been released into production with such a mistake is *clearly incompetence* and I am not talking about the particular dev (everyone makes mistakes) but by the organisation itself (where was the code review?).

You can't promote yourself to be a secure website for storing money if you can't even manage to audit simple code issues like initialisation.

My recommendation would be not to use blockchain.info for storing funds - they are clearly not up to the job of actually securing it.

Very good finding @bcearl, that paper describes what I think could happend (because of incompetence or not) and the conclusion is hard to swallow.

The incredible incompetence is not the fact that a variable was uninitialised but the fact that this code made it into production.

Unlike most devs who post in this forum I have worked on security software and also financial software (at the level that is used to run an entire insurance company).

Such bugs never happen there (as anything that is critical is checked by senior programmers well before being released - this clearly did not happen at blockchain.info).

Users do not pay bc.i for their security. bc.i earns money only with ads.
If you pay nothing - you receive nothing. And do not complain.

this not just about bci, you cannot use any 3rd party service that involves the creation of other addresses than your own.

OK, johoe.
Let me be Sherlock Holmes, and you will be his brother Mycroft Holmes

What can you say about this recent transaction?
https://blockchain.info/tx/dace266993417aa89bd8f68a45835533df16d82897c2228af23c5426ea2e3aa0

Let me start.
1) this transaction sent with sharedcoin / bc.i
2) 2.98507462 BTC sent to deposit address of BTC-E 1FuntC8m9SZwejEu5u8zNSbE8bbd1K5x52 (I can prove it)
3) duplicate R in signatures ( 0xf0650c1f66cfe7e317709437e1f830afa7485cad2bb45dabaeca2809a5e044f2 )

Is it the bug of bc.i or may be someone is using his own tool for sharedsend?

The R value is not generated by the weak RNG.
blockchain.info didn't create the transaction themselves; it was relayed to them.
Also bc.i-bug transactions usually have different R values for each input, this has identical values for all three.

This clearly follows the old pattern that we have seen since September.

how do you determine 1) ? 

Of course. Transaction generated on https://sharedcoin.com/ service
with signatures created by javascript taken from bc.i on user device

1. It is definitely deposit to BTC-e
2. It is mixer transaction (I am 99% sure - all other flawed transactions have this pattern)

May be there is one more bug in bc.i scripts.
I have never heard that there is public API for sharedcoin sending.

Hmm... May be it is another mixing service, which sends transactions through bc.i pushtx form. But I doubt.

UPD:
OK... 17c7o4YTN5JwjvdLLW9JpqZFc8wmiv9oEk - is change.
Let us look at the input#2 (last) of this transaction - 129b8GsK4bU71riV3hopab6wnqhPCLyeGn (0.05413333 BTC - Output)

This is https://blockchain.info/tx/b7408039ebbe5631891a79ba61d853ab427210df39a805f8fb6a35b3417198bf
also transaction with duplicate R ! Same person transferred  2.17 BTC to BTC-e deposit 1B87Sf84uYadF2TzJzJwg9k44UjZCWEWUF

output #3 (last)
prev from https://blockchain.info/tx/c26eb6b0c209783e0c035ae999020fbda198fe1a5595b69c1d51ecff0ab9f8c3

same person put  2.08 BTC to btc-e with dup-R tx

BTC-e admins definitely know who is it - they have email/name of this person

A way to dox him :D

I think the bug was not malicious, only incompetence. We are lucky that johoe was monitoring it.

http://programmers.stackexchange.com/questions/147134/how-should-i-test-randomness

Hello,

I'm pretty sure that the owner of 1MKSW... broke the RNG:

https://blockchain.info/tx/a66d1ed3907902660ae12f97de22276f34185ede033583545f7440e049f7be2b

The address has no spents, the public key does not match any R value, but it is a weak key (I post a list as soon as I'm done computing it).
They did not find all weak keys, yet (hopefully their brute-forcer is slower than mine :D)  Stupid, that I didn't remember the parity of the public key the first time I brute forced 1.5 million keys. Now I have to run it again and my ECC multiplication is so slow  >:(

Is sharedcoin.com operative ? As I can see, it only redirects to blockchain.info wallet page.

AFAIK, blockchain.info mixing now takes place from within the wallet.

Interesting observation from that paper I don't remember ever seeing before:


It means that two R values don't have to be identical (reused) for their private keys to be breakable, it's enough for them to be "close" to each other, so that R₂ can be found adding G to R₁ relatively small number of times, few million for instance so it would be implementable in practice to check the neighborhood of every R value ever used against the complete set of R's. I know that two R values in theory should not ever be close to each other if RNG is decent, but we see in practice that not only they are close but often identical.

That is what I was talking about all the day, they don't have to be identical at all and that why nobody will realise about the "bug" except the developer who introduced it.

This is true but in the bc.i case it should not help.  The R values produced by them are quite different. Although some are produced from similar k values, e.g. one byte shifted in the random number stream.  But related R values are hard to find in this huge block chain database.

This observation also holds for related keys.  Usually, two signatures with identical R value and different keys are not breakable.  But if you know how the keys are related (e.g. they are generated from the same BIP32 master key and you know the master public key), then you can break them.

Okay, I think everything is clean now.  I also scanned the weak addreses the broken RNG would usually produce and they are empty now.  Some addresses were already swiped by blockchain.info.  Looks like they used the weak-key generator I sent them today.  This also means that users having a weak address in their Blockchain wallet should see a warning when they log into it the next time.  With weak address I mean an address that was newly created by the buggy version of the Blockchain wallet.

Yes, I agree with you to a certain extent if the developer kept the application as closed source. However, in this case, it appears to be an honest mistake.

Please see:
https://github.com/blockchain/My-Wallet/commit/98d5a7ca59ef04d06ac6aee468634b12975a0f5c

I would not be surprised to learn that one person at BCI still works the same way he did back when the service launched and just pushes changes he makes directly to production servers with no review or testing.

I bet there would have been fewer of these errors over the years if k had a more informative name from the beginning. Maybe something like "ephemeral private key" to automatically make people notice that generating k randomly is as important as generating private keys randomly.

bc.i had two updates on December,8
First one they published bug, few hours later they fixed it
github.com has only one commit - fixing unknown bug

BC.i sometimes uses forced pushes which conceal the prior revisions.

I was just able to reproduce the bug from the GitHub info:

If you comment out line 29, your PRNG backend will not be initialized correctly
// Random number generator - requires a PRNG backend, e.g. prng4.js
// Initialize arcfour context from key, an array of ints, each from [0..255]
function ARC4init(key) {

Private Key:
20024245551370964114963921214810962636924048065379939224750754889731391894624(DEC)
953251A6CBDFCB91E38B958AB2B5013A503130194D8AA26083F7664E84FDFE49 (HEX)
5JwzcBP4uE5miuJW4tweMbFCz85pWmvXM7e2n6kSG8j9jwKFdTj (WIF)

Edit: Their quality assurance team should have caught this bug if the code was reviewed. It's too obvious.
1Mi8X7NHHYEQR95EnvQSciJ3ChCimt65SK (Bitcoin Address)

Tomorrow we will see a dozen of flaw RNG searching for weak keys  ;D

This seems to be recovery address from the disaster, 914 BTC total, they've been slowly returning funds to users:
https://blockchain.info/address/1PLn3ru1n7wERPP1BLVV9oAEGGuXUP1eoC (https://blockchain.info/address/1PLn3ru1n7wERPP1BLVV9oAEGGuXUP1eoC)

Does this mean the problem was not limited to the reused R values, all transfers were compromised during the few hours while the bug was not discovered? If I understood you correctly, if you seed the RNG with time-stamps from that short period you bump into the transactions which haven't had reused R values, that's how you got this private key?

Also new wallets created.  And "this time period" is somewhat ambiguous due to caching. For all I know there is some browser tab up someplace running this code that could generate an address and and receive 1000 BTC at any moment.

Well, that's not absolutely horrifying, is it? damn.

That sounds bad. Blockchain.info should put a general warning on their page to clear the cache. Till now there has been no warning at all, they are trying to hide their incompetence.

There have been again some bad transactions this night, including this big one from bitcoin gambling guide:
https://blockchain.info/tx/6bde86ea2a9892d955443d2bf3d716fa2c0c8947e2cddcc54e2a61930405f3df

The other exposed addresses are 12bGnGuxW6LRyCE8peAYnAFxS7fzVnSALZ, 1BCzSb27A3Ky8HuLNeAE9L17EVjXvo66z
and 1ALzByRJDvFH18CSVZ3YsTdGUkg8fmD5Fw

I uploaded a list of public keys (http://www.solidfiles.com/d/59ae939817/weakpub.txt.gz) (in compressed hex format).  To get a list of weak R values just remove the 02/03 from the beginning of the line.  I leave it up to you to compute a list of weak addresses from it.

I found out, yesterday that it is possible to compute the private keys from this list alone without breaking the RNG but it is probably more difficult than just breaking the RNG :)  Using the same trick, I think I found a way to compute this list 30 times faster if I need to do that again.


Edit: This transaction looks suspicious
https://blockchain.info/tx/45615ef3bba30a29561249a581e59b6e2b44e7612219735a1afdf3f76dbff849
I think others know how to break the RNG.

Edit2: I just tried my download link and noticed that it downloads a Download.exe.  Is this site (sendspace) safe  to use?  I disabled the link for now.
Edit3: I changed the download link to solidfiles.com.

Does not help against the attack from here (https://bitcointalk.org/index.php?topic=883793.0), because the manipulated random numbers are provably indistinguishable, but it would have prevented the ridiculous bug in MyWallet.

It doesn't have too much to do with closeness. There is a linear relationship between any pair of two numbers in the “Z_n” (with n from Bitcoin's secp256k1 curve). The question is whether you know it. Easier “k” is much easier to break, because it results in identical “r” appearing in the blockchain. Anybody can detect them immediately. But for an evil programmer who manipulates the generation of “k”, there is much more potential to leak values, without having obvious appearances in the blockchain.

Are they still not using deterministic “k” by now? Even a simple k = H(m||secretkey) would be better than any home-baked RNG that is considering Date().getTime().

Can some JS pro tell me what Browsers still don't provide good entropy from the operating system and why users should generate keys on them?

with all this talk can  please have a noob friendly opinion

would green address it be a safer option ? or breadwallet for IOS ?
i want to keep a small wallet with $20 so i can buy beer and show my mates 

When can we assume bc.i have sorted this fuck up out?

They have already fixed the code - the main issue now is that people have not "refreshed their browser pages" who were using the buggy code (and of course the funds that have not been swept from the compromised keys) and people still using compromised addresses (I am assuming that blockchain.info would have sent all affected users an email - but not all may have received that email or acted on it).

Private keys are already compromised.
bc.i can not do anything with it now. They even can not determine who moves funds out "owner" or "hacker"
In fact they also can sweep funds.

Strange things happening...
https://blockchain.info/address/1NEBmytquNcVKcQtVbVYCEXg7tNkN12QGK

this address was fine until today. It had 10 outgoing transactions last week but all with good R values.
Today it had a new transaction with bad R value.

AFAIK bc.i has set up an autosweeper for known addresses (and they have the complete list from me).  Also their wallet should forbid sending money to such an address.  At the moment I see no funds in any weak address.

Let us make fixes on https://bitcoin.org/en/faq#what-are-the-advantages-of-bitcoin

What are the advantages of Bitcoin?

Payment freedom - It is possible to send and receive any amount of money instantly anywhere in the world at any time. No bank holidays. No borders. No imposed limits. Bitcoin allows its users to be in full control of their money.

Very low fees - Bitcoin payments are currently processed with either no fees or extremely small fees. Users may include fees with transactions to receive priority processing, which results in faster confirmation of transactions by the network. Additionally, merchant processors exist to assist merchants in processing transactions, converting bitcoins to fiat currency and depositing funds directly into merchants' bank accounts daily. As these services are based on Bitcoin, they can be offered for much lower fees than with PayPal or credit card networks.

Fewer risks for merchants - Bitcoin transactions are secure, irreversible, and do not contain customers’ sensitive or personal information. This protects merchants from losses caused by fraud or fraudulent chargebacks, and there is no need for PCI compliance. Merchants can easily expand to new markets where either credit cards are not available or fraud rates are unacceptably high. The net results are lower fees, larger markets, and fewer administrative costs.

Security and control - Bitcoin users are in full control of their transactions; it is impossible for merchants to force unwanted or unnoticed charges as can happen with other payment methods. Bitcoin payments can be made without personal information tied to the transaction. This offers strong protection against identity theft. Bitcoin users can also protect their money with backup and encryption.

Transparent and neutral - All information concerning the Bitcoin money supply itself is readily available on the block chain for anybody to verify and use in real-time. No individual or organization can control or manipulate the Bitcoin protocol because it is cryptographically secure. This allows the core of Bitcoin to be trusted for being completely neutral, transparent and predictable.

The issues here are not with the Bitcoin protocol but with blockchain.info's poor quality software.

It would probably have been better that ECDSA sigs didn't rely upon *random* values at all (then none of this mess would have happened).

My guess is we probably have the NSA to thank for *encouraging* the use of such random values (being a great attack vector).

Exactly.  Blockchain.info != bitcoin.

I just noticed that I accidently swiped 7041 Satoshi from an address not related to this incident and sent it to blockchain.info  :o.

https://blockchain.info/address/127sp9ZQ2y2NbW3p8L37wgkvfRfxceWL64

To the owner of 127sp9ZQ2y2NbW3p8L37wgkvfRfxceWL64:
I still have >.9 BTC that I swiped from one of your other addresses.  You can contact me if you want it back.  Send me a message signed with the address from which I took the BTC, and I try to verify that you didn't just crack the address the same way I did.  And please tell us, which program is producing the weak signatures.

This was an address that I already cracked in October so it is not blockchain.info related.

@amaclin the problem that I see with all companies providing bitcoin services is that they introduce almost systemic risks in the bitcoin ecosystem. I mean, even when this is not a systemic issue, it is big enough to be an *almost* systemic issue. That is not good, sadly.

https://github.com/blockchain/My-Wallet/commit/98d5a7ca59ef04d06ac6aee468634b12975a0f5c

In a nutshell, just poor seeding of the RNG.

Because line 29 was missing from the original source code file (rng.js), the length of the key variable used in the function below ARC4init(key) from prng4.js is always 0. Which means you are left with only 256 possible seeds. Each of the 256 possible seeds produces its own sequence of numbers (which you can assign to some variable, for example k or d, etc) which can be used for secp256k1 point multiplication.

secp256k1: (G=base point, k=ECDSA nonce, d=private key)
point R = k*G (used for ECDSA: k and x-coordinate)
point Q = d*G (public key)

// Initialize arcfour context from key, an array of ints, each from [0..255]
function ARC4init(key) {
  var i, j, t;
  for(i = 0; i < 256; ++i)
    this.S = i;
  j = 0;
  for(i = 0; i < 256; ++i) {
    j = (j + this.S + key[i % key.length]) & 255;
    t = this.S;
    this.S = this.S[j];
    this.S[j] = t;
  }
  this.i = 0;
  this.j = 0;
}

I do not understand. Sorry. I do not have expirience with js and different browsers.
What brunch do we use? 'Real Rand' case or Math.random? Why key.length is 0 and how does "% key.length" works? Division by zero?

I solved this by try and error.  But now I get it.  key.length is 0 so "% key.length" returns NaN, which means it accesses the array at NaN, where all the values were written, because the postfix operator ++  returns NaN on undefined and NaN.   Is this correct?

JavaScript has strange semantics.

This is brainfuck.

If you don't use this code to generate your list, which code do you use?!? I'm confused, was convinced you've used their exact buggy code.

That's correct. Even though by specification NaN is Not-a-Number, that memory location (key[i % 0])  still holds some unknown value. So when modulo 256 ((key[1 % 0]) & 255)  , it should return some number less than 256.

i try this today
20 min download ubuntu and the wallets on 2nd USB , 20 min to add it to a USB , Boot up Ubuntu and print , would take any one less then 1hr from start to finish

I just extracted the important parts from the javascript file.  I understood from zootreeves's the comment in the github that all this initialization/Math.rand stuff was unimportant as the missing initialization would prevent the rng_pool to be filled properly.  All I had to simulate was the prng (which is more or less the standard rc4 stream cipher).  So I first tried to get the numbers from the prng initialized with zeros.  When this didn't work out (actually I would have found some values using this code, but I only looked for one particular value), I tried variations of this, initializing it with an array of length 1.

I just looked in the stream produced by the prng for one particular k value that I broke earlier and that occurred several times on the block chain.  When this was successful I knew I had the right solution.

There were still some unknowns, e.g., there are two candidates for k.  First, I didn't check the JavaScript code if it really takes the bytes from the stream to build numbers, whether it is big or little-endian and so forth.  When the first try didn't succeed, I read most of the relevant JavaScript code to check my assumptions.  It took some time until I realized that I had to play with the initialization of the prng.

Is this all browser dependable, on how many browser have you tested? Do you get the same k values in all browsers?

You misunderstand.  I didn't test it in a browser, I copied the JavaScript code and changed it into a Java program so that it would go through my Java compiler.  But JavaScript is standardized; the particular behavior with NaN and undefined should be handled by all compliant browser in the same way.

The k values are actually computed by my program that breaks keys with reused R values in signatures (also written in Java).  Computing the k value is an important step to get the private key.  It is only possible if R is reused, but I had enough reused R values that I knew at least some of the k values.  And I knew that the k value must haven been produced by the random number generator directly.

That there are two possible k values is because of the way ECDSA works.  They compute the point k*G, and take its x coordinate. This is the r value (Personally, I usually use R to denote k*G but when I say R value in this thread I refer to the x coordinate of R).   There are two points on the curve with the same x coordinate, namely  k*G and -k*G.  So there is no way to know the sign of k.

Did you use some special tool to do this (as JavaScript has nothing to do with Java and I am pretty sure trying to change JavaScript into C++ would be no simple task without a very specialised tool so I can't see how changing it into Java would actually be much easier)?

I used emacs :D The prng code is 30 lines.  It was trivial to resolve the few syntactic differences by hand.

Okay, I hope everybody closed the browser tab with the blockchain.info wallet that he opened 10 days ago. Because now everyone following this topic will implement his own rng cracker.

Hmm... I used to test potential employees with less than 30 lines of C++ that only one out of one hundred understood perfectly so I guess that you must be an extremely good programmer. :)

But a C++ program is a C program encrypted with a very strong encryption method.  :D

Hmm... well I know this is a joke but I do hope others know that C++ is not just C with some additions (they are almost as different as Java and JavaScript).

+1. It is my favourite write-only language after perl  ;D

It would be more important that wallets start implementing RFC6979-style signatures, otherwise these kind of bugs will always come up.

Thanks, very informative. I assume then that the problem is fixed at the Blockchain.info end.

The earlier issue was due to counterwallet. Does that mean that Blcokchain.info has no issues now?

The Blockchain.info issue should be fixed by now.  There are still coming some bad transactions but they dwindled down to one or two per day.  Also there are still transactions to the broken addresses, which usually get sweeped by either amaclin or bc.i or others, whoever is fastest.

I wanted to do a little after-math of how much money was moved by whom.  It is hard to get exact numbers.  Often I have no way to know whether a transaction is legitimate or if someone is stealing money from weak addresses.  I think every item on the following list is correct but there may be more.

• 870.7 BTC saved by me (they went through 15tXHJCjehqCEL6zRCkGwvuDY6YzZV5sKP)
• 105.9 BTC stolen by 1M77fUCzQrmY8jHRRgpzDVPAK5eQ31bwxZ (http://www.reddit.com/r/Bitcoin/comments/2oo72b/victim_100_bitcoins_stolen_from_blockchaininfo/)
• 53.0 BTC saved by Blockchain.info
• 36.2 BTC stolen by various 1xy and 1aa addresses.
• 3.7 BTC saved by bithernet (1PGfLgFtRHgdgvPNvmHMjtsWwF4fyG1jvh), not yet returned
• 0.24 + 0.084 + 0.016 BTC stolen by 1824bso2XgKTm7XThA75A2gdMpt3jSxW5M, 15hM4CMs7JZ3JjQHmvGhS4NKSsqhKMsQXu, and 1MKSWH9pShsLdV54cRLDQ9JKarsjXK4ms5

That's about 1070 BTC total.
Did I forget something important?   For all I know, there could be 100 BTC sweeped to various addresses, or the list could be complete.

Thanks!

They were sent to this address at approximatly 00:50:20 GMT 1M77fUCzQrmY8jHRRgpzDVPAK5eQ31bwxZ
Within 17 seconds of me depositing 100 btc into my account they were stolen and transfered to another address without me even being logged into the blockchain wallet servce.

I robot that scans new transactions (timestamped or not), awsome! 

The thief's transaction was even in the same block. That thief was quick.

Sorry mate, this bug was trivial to exploit by others. It took me less than 30 minutes after reading this thread to reproduce the bug. Which also included using block blockparser (https://github.com/znort987/blockparser) to compute and extract all compromised Public Keys and ECDSA signatures from the block chain as a result of this bug. Blockchain.info has no valid excuses if some of the BTCs were stolen by dishonest people and should be held accountable. Use Blockchain.info at your own risk.

Thanks to johoe for his honesty, we need to greatly outnumber the dishonest people looking to make a quick profit at the expense of others.

How your address was compromised:
114341855106315163431732800342145048132004074228743866970475626282250711110702 (DEC)
FCCB325269DDDA26D3D25870B9B326ED480B75FCBDCEA076964A87DDA590942E (HEX)
5KjcrjKnEofg5752fx8fGYPzXBaeQVHTdSqCuCzKR17VLULCeTW (WIF)
1QCRoj5dPAsADvzd2o7NBy6kywBEkfC1Xh (Address)

Poor seeding of RC4 (with only 256 possible seeds)
Generate a sequence of numbers with each seed (a sequence length of 256 should be sufficient)
As a result, you are left with 65,536 (256 * 256) possible k or d values for use with secp256k1.
Compute the scalar multiple of the base point G and compute Hash 160 (will be the Public Key)
Compute the scalar multiple of the base point G and the x-coordinate (will be part of the ECDSA signature)
Use  blockparser (https://github.com/znort987/blockparser) to search only for those possible 65,536 Public Keys or ECDSA x-coordinates (trivial modification to blockparser is necessary)
Output all compromised public keys

Number of hashes (Hash 160) loaded from the block chain: 57294273

Number of RC4 generated private keys to load (Round 1): 256
0 = 188941a3375d3a8a061e67576e926dc71a7fa3f0cceb97452b4d3227965f9ea9
1 = 80e0e182029293933495766768783a1b5cae0f766117c4c6885a3c2e2a3496d
2 = 106a2f3983db8d2e5845aee5c0134d20b419d241185528f02742429fd505bc2
3 = a211d6404bea71cd1be2ad397f9f663624a24fb0f48b5abdcc00137729b43758
4 = 27340f7f04afc7c96b88fd5666a426368cd7ed9349656eda08d1d3ec643e6a2b
5 = c73dbee8b24f1968ad7edd2b7fa1e9eb88c5449ae0ac3c22a21d3193757cac84
6 = 46fa23a9a3a219c770e80887113640f2b0e8b60af9ebfbfda42978ae9c6073fd
7 = 8828e80332162093ac404ace9e772319e9c6981542b55d2d8d37e837974b1138
8 = fca55b66be0ef788602913c38dcac2ae1845d80fc5775c33f719b85152f2786b
9 = dd74fd1a0daf41bb43cbbccb84a87e08f0747be4576536f90c97656526882ac6
10 = e4c3b6b4ee03a31c6688e75632cafe49da9778c05dff48ea5918210c4cc6699f
11 = 562388dc1f3ac07af72034c94e73aeeb2a9a9ac2012da8279ddf9cf28b8cdcd0
12 = f7eba4f7f692960b066fa653f16f0e32570d04bbb0f070060980dd0628ab1b26
13 = 741d26b69f44fc53e15c5aa6cc3d1c1a1afa79e35fa726b1f06bd409fdad4bf6
14 = cfb47f795df9a625c3d10ec5a321b0a2883f5a10a30a9723fdc6f5e3cd085be0
15 = 61c25d4d7b90b648a4cdba902419241f0fd37c72137515bce1a029b3bfaf06ed
16 = a632305a5575f33dcf16d9554f0562f0e245cd344c13ee1272ce7170aaff73ca
17 = 8b0f177cf68643215af609703f6b8028fe1f43e39dc0e3a4ed90738b3456b119
18 = 2e3fd17dc5f81c7d96d8799588ca64fb3578d8a122d8981f66f41ed47a39bf67
19 = 909c9d9ad33030a6eefdd400b5f72ebe6b90bd1767630e1cbfc4dd1c26752073
20 = e3f976c565e1da1b7b31d257859de54cbca39e6820a59c7c887a9c64dc1d85f6
21 = 3cd56453d5dc442aac71f515f92722a63c629ca83165ac3e7c1186b85f832a29
22 = 2c4552439ec5b31916a6b07edc8652be3988689643d9e295883e4390822c3460
23 = a1701261d9550a677a01d94be6eb24b1ece0911ab8dd08a54f963e7228076a09
24 = 3dc0550fea0d565ea64fde87867b81ce28c3ff309f3c0854322eab3cc5941ca0
25 = 3ed44c61b9e51d2dc4e36ab89a14da9cfe1565e35792db645d13921a5f99e83
26 = efc4529526e037d9eb9bf83d59387bb04dccc761003519cff59b2644d8c5869e
27 = 1b8bf002d90b6872dd92f17b23789d52e74372480e06b2285ab1db667f2bd2b7
28 = e11750eb0eacfedd8d8ac3984b1a98abad84f9cd1826e4f1d325bc23821a901a
29 = 762ed230918d5a22c46682a4c8458215cbf4c21948eceeffab39ae8b87321e77
30 = 7a5c599b3ffe2034016a9f0798f8ed929981c008a030a91d4bd5522488f9a6e0
31 = ddf244e12d7f00d43664be7fdb01bbae394297880308e416fdff57e8670ce61e
32 = ed0af2cf7318e31df938fe3ca57e7cbe5bd3e563cb7e290a5be1d09ef49e03b1
33 = 268c2d282b55c2dcceca3d478e6dc4597a975ef478fafc6149b67326f57c65f3
34 = 6f380ecf1da59804a9f0baa300d1e69ab4f8f4e3a07f60d2444c38b6fc2de7b1
35 = 6d91c54b15ef8047159b48fdcb4697b88eea010aef851d839fc50ed5bf93eb06
36 = 1f053af2341731297af0535fcd6c85e91efafe3ceb4616f12dac83737a588a4e
37 = 7e0bf4a11e67b21788c438fe6da3cb8f9ecef2495e4ef49e5fa84fec050d2e18
38 = 197dac4597ab0246fb2166c8fddc3e3ba31b86830baab134ffccc04c64bf73c5
39 = 3fbb21d9cae044910360ef49dbf89044740d29dc2f351cf7c75ab7a2ac1dd179
40 = 31ba0d1dc1eda2d77b6bfda69b2eb050db6bdaf474c12e99784b7929327c2a51
41 = a1a38f716fd8e029bd23c8972c7eb045cb369f224c5635d2cdf649662635aa6e
42 = 127effca11359e7f06c6f0ffeca469ebaaaa9bcabeb6551d3660a114050817b4
43 = 12a13bf73d68271bcb3ed4ad4c165e10e13debea179a326aca1d4b43fda54b15
44 = d15d191dc8087050aeca0bd742ed6a74bb9de17957daece6d08f1254b40b639b
45 = 6b49d33c950afa68b6a0c355cb9e2f147360157ac1a3c2673506574e23b4a6f1
46 = ebd8586251eba5612e7f0ae1461b85e7d6d01870ed72cae8757373597800971
47 = 67f81ca59a5ca45fc44dadab563516fcc5f241a91caeb494a5425ffa4268a931
48 = 7fa680c37bd42734ffe274f1665eba87062cee556e04b2893efcaecfac7b9e8d
49 = 1ac26d9747ea72743c1dbd4a67a0f456f14a1d6f2f723366b8a3eba53c09b33d
50 = f7a0032b47e85a09f1ec95e7878e5ce776b85d08b2d977a44558d3b899801c9b
51 = 50fa8eb14ee500784771439e20c37ada7ffe8ee5d7e738b5757d33cd8ba248e6
52 = dff40885eb8184959b0e17ff1d27e5b93aa5e4a9b796d79bf9b9e8773cdc40d4
53 = 7a4a0d8afc49eb9bd7c4dc5b4984254e6b5936a9a9f3f107186dd9920d58d269
54 = 59b77e8aebd0cb82661dd174ed9bd21b05a37c6cd1bfad69e2ec7799253d81d3
55 = aed9060b90ede60b9368a6620a6fe59e1acb360dbad1dcdf6ea8974b6be0b4c6
56 = 29758d1d7c3e03e84d8262b9506b71f1f9f0e9d9c8bddae245eca3e032c448ef
57 = 947b9e99cb13f7d5a00485815a5bce49a3185e45318d2942ed65744a6654e8b7
58 = a0e4966faca2aa7bf70392146bfc7d79731add9e978e00fea40dd2a25c8378b7
59 = f425e52f3b136316526de66091a6918f4955619d15d535943327d8d161aa0966
60 = 1bb16ad0410d4c364350246db1e8d026a9e8d718efe38e3c77c2e3f35b119e37
61 = 1e68fd5ef1cddd6d013859d6fe0db2d3f5309faee259d759ff172b3220b0c94d
62 = 71e9f58a98882d07bfa114dc7ac46e7b84abc6eb02c3c2e01feb21e8315c2e5
63 = e3e275254fa36a1c4048d58f8f92a291d4dc6c99624745b27076ff039a237160
64 = 792dffcb4caec516dd8159b1e478401a006efae68b96fdfa6799ba17a0285e33
65 = cbe63dc0a3cda1baab695ce4f0352b774592b214a905796a6ba9fd30e0ffc56e
66 = 7f56c8741e546fb97839e4942250487b342c64e25c0bda66d57c88889b8f8ae8
67 = 367e17b7d0bb57474aa124b0cc0a3c48ebee083d84e6da8e6f7da1cd4888cf49
68 = bfa0915178e1b5f4c6f6a7ea51c1ec368a194e1345647224ba3ea4662d462e57
69 = a96d44d458cf190e6740101dbb97c22b56097d88fdfd5eeef9334d71b1a27bc4
70 = 543db1de2743e3e86172aae7de00a1ac43721ee7cf327fc040c0db3739e72d6a
71 = 742757664e2f5a5f8bc99a8d574d7c7eb0be3c8fe289baa19293d3b24c890f55
72 = 6a363def51afce14215cfee38df0791022bde69c42fb58aaf927be7e8186fb28
73 = ee4cc5cb3a4046927530c04d21760383831d94a6916bb786b90b3e8c8843d8e0
74 = ebedff9bbbdfc2e812db9eeae059564899e1c747919fd57b40556b65dda7fabd
75 = c4e50eaaf585ace47a89e775498b41c3e085a13ca33c29a31950cf73f04cce8
76 = 2589ec4268f5bdb274b1713c57711e28454985d603e736fb571da0ca011ac54e
77 = a6164ce9fe651b7ab7dbb2483587db385891b7c430ec93b2a1994f166192e53c
78 = d621ae9ce615353fadbde76d42d2f4b94dd8450d923c596fb10f23f69f697991
79 = dde1374165cf33b1a48e2a1ed9d5243f9ae7a58586bfa22fec61311952e7d2ad
80 = aea264f0ea6e15b9d2d2b5835417852b8e22084b0ea5fbd9d6c7a4e1dc9f8a8d
81 = 2fbcde513b42a44f17c2ae9ee8a8fbc5b200c7a8e38a43f93c1b0b3f3de4f8fe
82 = ba93dbce603143dd1c6bc80425d380a0893879da1c8bad841788750b819c8448
83 = 4c739787e3649b8b00b8ec0398bd7408b00a01945dc3b8f08210d8e8fa49c8b5
84 = 73a299ff4ebdb2156d97ba50e04e06bc5a67da72a10e9862fa52df7486581710
85 = fe68d800f9589a9ed7578a4b3b35450bb845c844e574587b4c2e459d36ade133
86 = b725b564bf2af8fc3cf850d29570b87a3fe93e005aca56ca34af65f75b2420cd
87 = 195901a0e965b8a91f03a29d118c42604e5909a9c23bf2de6bc3b093a637450b
88 = 80f1440e70b6c49c7a8363d456368953469073bdd84793afc918f314efe51785
89 = f6c1c86025d9629901e03d6c267604b2238cc9c72fb2dc12d698db5b19f1ff60
90 = e48043641915cbf387bfed3669bf6cb2116fc8ec6470ae5e0818d0a01761c0d4
91 = b2376f5438690985b4c0e5aae090286b7cf5952a1f9d01b763cc3c458d81c031
92 = e0b6bd2f72864447389b1455ddd945ad140aedc3133b2998411eb0ae1e6e1ac9
93 = a01794aae793e9126860361708f23e1f84f5069ffab273a65077c2ba6ba0d3e2
94 = 8c53c8614c9a9a808dff002a44415c140fcf2f3ec729524bea2a7284d0bb46ff
95 = a687d783c9de8dc7e2ea470f607566f9e1252cc6cc299d615af5cae53ebe8832
96 = e90bab4deb358fb1bf5691a8979af06af248b7613b40bc6a5261d9535da3bdd
97 = bc981e42d9854b2e6dad275c1cc5cb5c6e89d751c24c7c6735a4297ab8bcb8f3
98 = 8ede550e856594f4a62b4c8cd1ae693fb19ea5ad49c46b0dd46ddf6089ed9c4a
99 = 25d395e9ac3605ed61584461c663171819410342401db171ff703a3668929c69
100 = 67992705e9c2bc4c0f35d693f19f4fc3c3490238c698f443362264f66310959e
101 = 96419fece5970f51180460b37aa75f2613463d8f64dbe64db92603eb14023b73
102 = c805f16945503ae9a9fe7399ef0f62b1e3b6e2c423649a2723cbe3ed9bd1ee33
103 = 953251a6cbdfcb91e38b958ab2b5013a503130194d8aa26083f7664e84fdfe49
104 = 4da88d57e9d051f99a464dd1abb47fd4a93e5871f2b6ec3335096afe37e93cb4
105 = 1509317a30002e77f1ed5d6a6e9700eb9e6050eecad2fee29a004e5e53451819
106 = 9a9c3f7ea08ba2589730c20c395797b5e18beb39820636cc049ef05a4ac7a9e3
107 = e2a051c7cfa68e9b66e4bef6c041432e5a32b8b56540d89e709c9960d53e6c55
108 = 8ebc559db2db899e3f0afcd2463f13ac009b68af2cb58e01647ae2628aee9dec
109 = 480cdec2d02dc9e308f67aa0413393a9aa4bed1d4cd1a9c4658b084dedff7fc3
110 = c16ce649c60c9bf8af489000f4fa9be7232122b4b8502a7f27b097b170dd284e
111 = 710f5f9deb3d085c0cbe17e2049464e80a4761d6bbb8638f4a5226d1499f715d
112 = a2728827324ee3d7b2546eb8ec5d41d75b8e9a6feb32cc911c6fabeff6fd782b
113 = 80fd978f79a956d1c5e882d80aee8d241d272380848d9b75073616b0484fa025
114 = 2d2b629439f87a349b4963bfe46ada0070a0cf3815aa49195261c6bcade30ba6
115 = 5b0193937d34a48ae9ee6f373162f762c8b6c2192da420194a99b1faf0b4aa6b
116 = 92148b435876f7486458e76ae7f2e7ccac57fd7240fced4564e856232f3a8461
117 = e22acd31626e032c70a103ff4abaac5f8b447b5c889abd55c8638ad6406c0503
118 = 7ef056211e8138273e007451f6f8966bcf69d32fbe1ad537731923353d01ea4f
119 = c876d383567be423eb3f1374095dda38924c02ffb52fc13c6124c5dc39592514
120 = ae3618c71053d60eef430e5d3b74bfe235b7db754d3439d7b99d0e50a6b82832
121 = 84a44284e74935e9a0aa7337c4813d017f75171bf644f6dcfa00dbf8a8975b52
122 = d3724b5ead2c8937efcac2ee93aebf4134ad683c8beb9d8e9e9a34982593fe46
123 = ad341e28321cb2e98bbfd7a3ea47aad9cc546d5ff7ffce0b0db79ee6e8a88596
124 = 2c660c32ebb1ef6311dbd863fb2a58bfa04fc52cced531a06b7ec2ae1eb305e7
125 = fd83dcd31f1c66a8f3e06fd0992ea21c58fa4e1b69744820258a5d5a800d4ee9
126 = 3b4cb98559c692cf5f6c53099fc5b6fe13e226cf779f206b6623dc42426dac35
127 = 8e59aaa598d9d95bf7f4fb1f953f7c1e3e6eb09b76ed58927310f25fdba8bd03
128 = 8b60fe87057c21c8a860efc73b902061bf3b7adfda06da4ff1fdf831dacf6f96
129 = a1647757376fb4d0ed8ed9974d63abda1c1a149205d035ca094a84f08fe52237
130 = 9c866fbe75a748ee7cfc21267559b5b2958b9492d0c20918d0f0ddd0f48fa931
131 = 983c9217c9dc8e63506cdb2787ca2d0da1c672107823ca5a3804da79d1125880
132 = 7b6ad01241224e9fb65a703f4a110999a61df63de07ae5f51810c302be817b4b
133 = 40dfeac0f9d54e88a2872ca1f1f81910ce157667b2a64ebb5d7545ea0c433c16
134 = 86d0f14b3a2d569514d43c5a1cea21431032364dc6051a48d9b27775e01c6fc7
135 = 8de6e364b6af2a8e7cd732b3e1741e253dd39c759f33a2c0847c60d0e74863c5
136 = 611a0f227fc9868541fc82d8f03c971f869e4fe31ce4240973aba5e0e185cdf5
137 = 4ca974a86ccfc278c4207be58c35612be890a1311c22753c59ff94a4aa50b06f
138 = 195f866d7cdf83787b30de43fc1ceab7f73831c7013f5ee48a2b9539ec6dee09
139 = a0f3adbd6292fe7adea8d834226c5fe78022f9fda84f0fee1d3cd65b1a683be3
140 = fe38ae76286be0719aa073109803015dfce70ab89dfe2bb73233efdaf47a79a2
141 = 41b301b75eb97d62aae5757727870cadf53966b45835231e81e6693533c40685
142 = 1d839eecb8edc4ce17fafe6430cd4f593d422d6000cc7419c243f844359d0380
143 = 4bd0707d04a28f1d40bef158dee970601716064a6923116c900438b289244b08
144 = a6cf0e5dc1c63e5ddc15d04f79343542dba1d2ffa3a7f1687cd34f39b790fe51
145 = 9ea96fc7883a71f57cfbc0ec777356a5a05dfac9fa238f1193a4fcae57074633
146 = 4c1f558aac55d556dead126781d4286adcefec7c8fd52232491e304943c3d822
147 = a161cc2a1698cd1529cf4ecdc634518a2ddcd84a778d3fb37389040fea2f5519
148 = ea87123f790a6ef1a7230bdc673ecfe9467905ac3013607f44b9e25fff233bcb
149 = 69b7eb0cfe9f91cb64450e6081463804d59bab5c08f4c85f835a19b0e73cc23c
150 = 90d7e515f98ae640327d8663266523e4670f91106eb72355634588a44f879817
151 = cac29b7fa85df2e6a28b4f8e9a5fa5e35d0fb0519a27777c0c22fa74a0c2a32a
152 = d77d6e93ba3b73343aefc5bebbe1820f3d258b023040c1077e2eb8a9bdf522ca
153 = b5c56460eb9aa61361549ba0f878de1cdcc3bdce8f2a88f5030fdfb962d1c642
154 = 8a2dcaa49fdb84a179070d98a75027f29731f52e0adbf7ff48131005be45db03
155 = ffe08a1131a13d542ac86ca912f35ed6115e17ac22db472ffad6342fdaef581f
156 = c41cbb098012f7a5148d5c3501b312c4d9d4580931bcf30cea976de6917ce766
157 = cf0cd58548a57f66a6a0b9ea6d64125baf53679ca56e62d49cd72a29defc14a5
158 = b0935ec1508b266b656174272bf645f8180de8a211835266050437744b27be32
159 = ac1baaaba130762601f92c2fe201d883defe9c8cb34baa97699c73c4cf6fa0a6
160 = f1f27bbe75e369bdba5de062d7e0b631346208cf809b94d6f7155db61672ba9
161 = 17ce6a514707a6911c4413c5b1d976ba7ddc90a08b9348626ac08a7a23e4c123
162 = 1467e879f3498c8a4196455590f0adb221c9febdc9a0fb98e5b90e0319754bc2
163 = c6fcec891be5fbed5fd50d9b4f841989e4364a06daf4c1994a47d6d495bd705c
164 = 322a875a5931216bdad704421a7e11c7b8daed55189ad44ffb69c9102fba0413
165 = c1271ff9c877f07014c429b2c1e4be8d08973d5d2725cf5f4b303f75e2aad355
166 = 827c7a4a38ad451043e6d4c42845f3d4896b5b024524e4a336813904182110b1
167 = af4dc8af3042dcb17e18c68c15d5c1522af0b365038ec625d49757004b748e2a
168 = 6c1653d90eb75d829e3b32f6a9282e3500a1d95e89fe1ba757e54eec10bf8c75
169 = 58aeed43c847951f3328384c8461f3b84e39c51a97f7e298b048b8e6aece87f7
170 = 686fe74238d147dd717685ad307b8fb3353de08834d258f3d31ced3c0ba9e3f4
171 = ed007b964373584c7cd267678d895a824e145574e57e956a7cedac36f10b252d
172 = 75116d4a7f53835b18e4e8a3a462acd52b2958c4ac7706d3d798a220b8f1166e
173 = adb4f4a96af2486e3adf8b44bcd967d83d5216967b42f658b8a547e22ac1ef00
174 = 2ad54c2b2b7585817cdf124a78b96c8c1be3c68d87dbbb69b052fa4ca06f9a02
175 = d545132288fbe6f6101d97f90be951a82551da8446a14dc7cd13e99462f6f802
176 = e8da1b70edec22d7c709a0a216af71ff2b0516ab874fd1269f2a485c4a6bc237
177 = 1afa3d40ee5c3cfc84704878d584728d4d46901af296ef3d4a2dad5ff4fb4612
178 = 7f4af06b88d2b642a41a65e55ffa35a52cfa9b80673c1309d6e1f938832b295d
179 = 5f7ed9412a41e4c54ef0810a01b35a4dab4f9b92765689baa8a3e10a2570e2fd
180 = f615c0bb16f9f244c2697260d735ae8707340a387c6bd5506e4fe7eb004ad7e3
181 = e5f4987b89ee0acf77eec01d79c2cb85202c2f81b1a0a1e684c2332ec6c7305b
182 = 70f03da0c402f09d4c7d819c3f7d8a3f5c8a3b6a366b428a1f4868e6f55305b9
183 = f8a1c94eac2f2a0edd6bc0af6726fc695b805c7c7cfc93062e44f5f10d3b4026
184 = 83965d733b2f9992ae762e8d3fa11096205d93716e6b12789e0668c275cd3afc
185 = 7f7590ea11690345b486fcdcf91548f7433b370688b331c30841536bc27f6af9
186 = 6d2c959a8e8c796a37fe4e24c7c05ae39bf8a44235d7880da3a0cb77f6f81a2e
187 = 9fdadccee2e4197bbfad0296cbb4156b8cb0a821b26fb954d02a390a66c1d9a1
188 = f59e6e36131666a38a563f01ebd89894f32358cfd56ade87b3481854be3b97d2
189 = 358c1039175752a69934268a7f6352ace89ae3b65e3cbb401a5e5701ac9e8e36
190 = 898892887e18bc3791b9c58feed9e3fc176ff341d3c53ecbea00c095488e696f
191 = 81349c04be5709e81dbc9fccaf841de05669e9cd9873604d9d17127dcd8da4e2
192 = 6adc9e0b1390a97508a9c5014fb2b01071e522603942651e4d9331db85b62600
193 = 2728fab046498b29c77bbd378ec2cf2fb23c47049511ffeb8a46a20d29f8929a
194 = 71fe736334afaacf9e9fe6ae4037186a0637e7a9ff60af25e4023a199f4067da
195 = 7626bb833897077a6ec0a325d2a6e36d483bdb7ecbaf1c3e3553f06be47d539e
196 = ce8f4b89210a2587f09bd6dda038750f8777e264fc48d2a75ce947d657b92e8d
197 = f521b60fac38ff99a564326579401f8f188b228bbbdfb814c56593cdebcfda31
198 = 720075ca7cedeb7f06561c38b4115977c9f4ebfa50414f5dc91d07c42e9a51ea
199 = 856dd550dd3e9bc111aefbf0a60221f6962e4fc60e5544161ae357c25d776445
200 = ca8ed3f8761e471cf9cf86ab56dfa2b5f927496f78674877edc72b7ad1e6fbac
201 = c2566d4471a012a1ed806d3bf3840250d7000610c5a2cf4429cfa72959483023
202 = e4e6f727897cf410b858b8d0088d8fa1cb9120434e2bc5626eed9314269683da
203 = 22181f4952f2ed436617d2d7788fa8dd6cc5d64cbf39b8d697943cb6e596fdf5
204 = 45145aa83a6ecc3f38d1ca48ddcfc07660c8af37b9abd4a0097ef5cd7d1e15a6
205 = 1b8c10a9bef442c55f167775b4f08d21aafb975595155235047d9b95d3a335af
206 = 2540854d7f6adf54ef209c27c125dbd3561d612d742ebf480f8ec22215462523
207 = 80faeef5aa58bf5df03c9272a1a945b420e1588f8c2f00fba74434aef070172e
208 = 2219035e8da17fd8d4030bfc347e442078565d53b7d06c4e2afd22d94c08828d
209 = 711633da9ca089892499350b8bddf9eed9da479aec9bba3202a22b4be661be06
210 = d8d81d8d79616b81cd70e171986efa1f62aaf02da2e8eb676fdaa6c4fbfe9437
211 = f62290205e4a1e895bd391af8baf6254b6dc50de2a9a4e27971002620b7d230f
212 = 5f9c74b61e8ba633891a87b8affda157029e0d85170d12255a9687d97e649336
213 = a174e255dba8b13bad2272bd7e11a90d5b280c307b1eb8a5103b9f572dd4da52
214 = c9688fcc1723b7382c52108efe95085c63bb03cc549265d957ff762a5aed181f
215 = cf2462552d6e564283adeaf3add5301efac78236c53cc7aedbe2e65b211fa450
216 = cf5424b4a0454c630d39d71c30b6485479c5f36e91834e3dac031dfdedb43e05
217 = d8efbf41f2dc9f5cda3cddbbee76abeead5f1481f5acf8b2296fc3c2444dca99
218 = 23374e33e1416813520eba1e4ffef577e91739766c2a57f13b0e21955a06e49d
219 = 535a86f71e12db8d7f76148ac773ff2cb84b9a4df6877d10b502352d7c32a378
220 = 9c3e6c35081bdcd2f33b0e34612348e1adcb27fa2ecc70935e6731b928e5364c
221 = 7e47577999c119c8b86d8f3fdf314dc854b7ff04119d2e920f61d6e9897fc926
222 = 160333106c26e8178bf4c493823165099371469977dff4d5095378dd6c81fd2e
223 = de293b750e83b0d39672e7c04eb64fbffb957a263f19096211c3fca222904f59
224 = 4e0c049bcf04f59d30afbbbef647a50cc125985420015ce887c38e36d664cf49
225 = 1ba4dc2494c7c80e66aef290c493bc2bd03c5e838a28ce94aa5df108193043ba
226 = 2503f6c6e845b5f01bdfa46ae8c0f33e2c298261074b7d4912d2604c55517a8
227 = 65fa5e5b8ef0a073d5e16a131bfc0c9fa8b93931c71f74d118360d37318ede98
228 = e7f107aea3843c4386784d822b90a94a59c5b66f10db3de6e5c9a4257bd59a4d
229 = fdc3b41087404727003aa6da88911ea88cdd26f6fe2f021fd112d87f65c7cd67
230 = 4ad86a30424a417d62ebd6fd2d2a7f8a0f46cc4bac633a173fd4b04393ba044
231 = bf77ceac6d66df3cbebbc15cdcfa33a3291aff998c6e0135eb64e35f840205c
232 = 91402b112825126b94cec3911197e48445a1fdf6966cdc2a732df84d5875ba69
233 = 8a5156a1f4a3386741be4125fc38748eb73ecbf32dda618c78ee14621265848b
234 = c3311e9998f517a573f8b5aba5a473843fb5b568e2a3ca60b2e9adacfdb960f1
235 = 6728cbaacaf569d3c09403f62130d6ef79edc62fd8f903c85ca9ccaf4cdf0ce4
236 = 55a979e581bdf536fc3b288a07a57a8100f5a7ef20093fce225008ef828de120
237 = 91fb62f1e9e6013ee1563edcdfc15b5f5ed22c8c76de881188e2a0d045100d48
238 = 7089f18780d4dd8593a8e18851e1ba371e1b6cb9a01cd317a79b8a57231bd321
239 = f758b773976f91c117ad1375d5acb63f611367c1797fb51975724c06a7a8a651
240 = 6c5a103cc9503706dbadf257c388fb07150ac56dfe424fb84813645d70e1baf1
241 = 90505783c453339308de56b8bae4afc8321a28fc2db5346784d2cffda8e7c44e
242 = 7e433a595f2e3a649b07332011f3e673788e5e454f00c44efee269b8bf6fdff7
243 = 3c60e61f9b9263bb4e1d495f5afeac8bce37d54949f15d835da8bd5fdc637b8c
244 = 6b27d8f7c9b62e67a19dffef5333ea9f556f69846831b73e4c26fdef81eae658
245 = d7e1f4570eeafe2e5f9c7eb33f7e5221920b4101706917e5ab39d70f15282c50
246 = fccb325269ddda26d3d25870b9b326ed480b75fcbdcea076964a87dda590942e
247 = 8b8bb0dccc3c1f1afa05e2342b7ed3481a0deaf999fe9dfc0bb5aa43861eac95
248 = 9e69f739cdd6bf66ad9f083d3801ed790d1054f7e43403885915513df7a3382b
249 = 8d1a57928a1b293f776ba8b6f99786b167da68c9ceb539b1b4319f90c7b965e9
250 = 7d5aaf6ddb07982c34921c1bd2ed4fc49e7e5585f496e23d4f5f121671ece6aa
251 = 8b390159b19781a8640f229ecf23cb07ba91d6463d0bb2125a6bc4d1ccabec6a
252 = 60c22230ae9fa569431cd975cf6e2e9ce0b2e16097dad2892212b9c745b96c06
253 = e69a721981d35c551ce555ed0d5f24e6ba7e839c0cfe4b49cecfc8ea147f9a1a
254 = 171f993858c19e920d9b90bc0377e0f8609945c2c8eac592dc5936c1643e198c
255 = 252f2470531bb0394b93b4c46fdd9ce8bcf0f16edbbbd3ed4573ec5198b8e6a3


Searching for matches against (Hash 160) hashes:
2 = 7db7c7535e0991649ebfd0306fc386f090526e21
3 = 6b2f1a0c84c08359bca8908d347ab42a9bb4591b
6 = 33b260edb9eb4b5f4b799e8915ea072036a522c5
7 = 4f72a001bc40e65bfa1ae46d8f21f767e3dcc7b2
8 = 16342dbc831017788ef7e0694c38bb66630cfd53
9 = 4e944938de9334373e012958c98e7be6dbae5c4f
11 = 39fb0f691436bb05bc09d94e819bb679cebb34f7
13 = 4a7ddedb2c6d245eef21b953646afb4f5aae7037
15 = b4c441a4047e4dc6f19256b48401c9f168f31c30
17 = 7079bb276d8b6e73caab2743f1ca94bb4eca944f
19 = 329377f7c38ce310432993610727341912ad0280
21 = d0359477f07a8efa89c01cf5eec2b12e34d4eedb
25 = 8e8110e7d9b65e70a6199c3e870b3bddbc293e71
27 = 899ba1d29e06b255e0567e9f0d01b0fcc39927e7
31 = 94489dea0500456ebe147137b062d7063dc67983
32 = 50e95a26fad750accde88223446e93e530e3b6ed
36 = 70e29aaccfdd329f6396614a30ceefcc8cbe9e3b
37 = 42da992ce9da952f5d94813a44363a787f063afb
38 = c723f26735e0cfeb3b546df726a13511dcb074c9
43 = aea0d31298d9c05577740b80ad7423c4a0610817
49 = 8b6e4b4b7fa08df7385f29c3090aaa97cd26b09c
51 = 7697bf7d127e750e2fdd1c288b392d0b50fe15d8
59 = 3836a5a948a9429017582627100c48c1b1d37091
60 = 8285e0c3e27ab69fdd73b92e511c01ed81e268dc
62 = 9b1772cfd3993cde2bf974672baeb8b911bc988b
71 = 714c7dcca2f611adf8ed02ca4fe761e66a22f9a9
72 = f1672e9ee0970a4c68340ed7648f3c26f39f217a
78 = 51e03a6ab6a05c90ba4348e65d8cbddbb16671b3
80 = fb52e723b73db20558dfdf147a262fa9223296a6
87 = 0f01f0891727860457e13c056f3e151a141c0d30
90 = 38c32212a5328c2bccaa53c4c37d2205a1012430
94 = 4ab50d118c59ab745d50340e1e578ec8b35260fd
95 = d7a1538475f71b61c72f7f43b71be4a4c69b0ba9
96 = 4f75a3b1ffc0b86623bbba55b522b68036d734d9
98 = ed9bdae7f82341e249c43e10bb4419b33f7a3805
99 = f7528f21d699a8b01b0225f9af772408f32a343b
100 = f53dad77702e3394f449606c89363bbc9a4b71dd
103 = e329d8c5a6b7e941536293adf69e488215cb4605
105 = 4dc343923bde890759ff5d51d0d1ec688cb8f6a0
112 = eacebd514452fb85aa5b41bb591cc2dc58ac0106
113 = f8de3df8cda4e4a00a7fe711c18ac8dd6e9483a5
114 = 499fd8e6ef22660d0478887c18b975eb123e142b
116 = d167ac5fc49bcad5ea3af1f6027ee176673cfd55
117 = 5e1f5f22ffdab77cc187edfbf33abd3084f9bad8
118 = 377e321e8fdb45ecc3c9e219f90e84c7ab7673af
121 = 5d796ba1049923b80292e508089e90c7d06c7644
122 = 4925fdaf3157cd78847954a89e4d1aea52b78a8d
123 = d4006979f6888bb520ff046d4ddb4565b4efcb52
133 = 51fb1d8e9918b0c8d510cfd261c52914ef2cfb3b
135 = a630220e2903c5890e7a1d47c85e1abf433d2a6b
140 = 0fd0339417478f3bb597c7b03ea53696a401240a
141 = e165904fcd411d8f9a62f1bec975c2e7f892fe3b
144 = a29b42e79c74b6b9a7ae9e67ed4b98a8a1ec22d7
145 = fa50340142612ec217d018a43359db835b2173d2
148 = ff2afcd753c4df9f0115fad27e4c1d8156a54f97
151 = 935e9279487d4e881da00ce94f95eae09f29e60b
152 = 45851539b2202afa66d1624c1b7d10604097855b
157 = 30dd7cbe29ae4bcd5e79e41754d091486c36488d
158 = a9fa6548a8577b56b46a9a9ae9427b59e9d64021
163 = 597029313231744629e4a4837787797d335aa52b
164 = 0c3466fe64d192ffc3df3c85a46a5e9e0f360764
172 = 4867bb6e0bf1c42fe2c30359c852b1b621b391ea
174 = d9bcbc21a062e31ca8aa885f17ed4ce4ed38cc23
177 = 989f7be9bcf1dc2925753d297f71f649a2eec28b
180 = 5d184bb9fc8785bbe92c6332ff4a2c13fee358ef
181 = 5e69252b60a0ff1cf19882b45da6dc565a501ba5
182 = df5e273aa4680d744c603d79196368aadc2f7c47
183 = 3902f373b09acc51a7acd3995f1efba266a8f9e6
185 = 926f4e7881762ab80809484082f96d236fe78562
186 = 7393d4b958228a9682ee584ea5656d0493fdeb23
189 = 23c537028821f079c3b606946d4f93139257fb0e
192 = 2f3fd530bd7f91aba11a47b37fb4622d265b6ecb
193 = a5cd9f5f94af65323d7757c35c319356ca38faa7
194 = 6a2ba20dfaadbae3a19cfe8e7b44504b91ccca7b
196 = c4f18e3b5cf413e192dc9ebf6716952bb027def0
197 = fa04562d4a9d8db8fc444506370521ea335897c8
198 = b3c28d557b4d9a9a4b860d385a1720ce9e5da33f
199 = 1d3a5ef42c787231465d3c6d0a756acc4c506c11
201 = e3a54a26c3209fe2940b507a12277a60a49454ee
202 = cb010887b46569b89ad538dd7c75a5c4af552d5e
208 = d2d703c8dd35e380a3c7b647391556af18fef5ed
210 = eec254fa3a94383c23fa6c4b822e7202d341eb86
213 = aa262474c9d9be0ba7efd6664afdcd51e984b361
214 = 67e0d51ff08bfc162971d164ac7488b5181b6ad4
217 = 953bf994a2a84a2c1b62590161aae9758341cad2
220 = b6041dceae5ef8ad8948dcd1a55921f3800487a8
222 = e45a4f495aaa57d2fd3498aee612e29f18068e1a
225 = f5a04566080ca573301f37a3ee729c04591f2bb1
227 = 9162bf223360617783f0060f5b2e299d557f7be2
228 = cffbcac199998769b9b5a51f6260f5e9754edbaf
229 = 8591d360c86e9b2f4eb60fb1f74567f95a6a8b35
232 = 9508e73f51e6244ff5835b979a247f2ade6b7a32
235 = 5ddc5a6d4a4eb0d673f07ae5174838ef8fdba5a7
237 = 61c141d0e3eba1afeea0e17bfe3ca5f33ac8747c
238 = 7da706f904dfbb68c81381025b54009b4b78ffe2
239 = 36e4bc17cd2f9a5085a5f76387236c1756e5b1e8
242 = 3c098f3d1ea3f967fdfcdf38443d5be6ff6d1469
243 = 39ba305c710188f70d137f9f5c645598d9161391
244 = 6c39b8461a97aa863f78b3d4f242da9dc03ee92a
246 = fe742cdfbc52ba07479f0b84eaf1a17eab016de2
248 = 387668cf3e688750cebeef4d0763b32af482f068
254 = 371ae153fc7bf6a4c507702128bd3f8c644995f2

I doubt it was a bot for three reasons.  (1)  This was one hour after the problem started. Nobody would set up a bot for this so fast, you have to understand the problem first. (2) the money was stolen in two transactions, first 99 BTC, then 0.9889 in a second transaction.  A bot would have taken everything in one. (3) why didn't he set up a bot for all the other weak addresses?

My guess is that someone created a new address and found 5.9 BTC. He transferred that to his other address.  When this worked, he looked for more and created new addresses, maybe also new accounts.  He was still online when the 99.989 BTC arrived and got a notification.  17 seconds should be enough to open the send tab, enter 99 BTC, fill in the address (it was probably in his autofill history), and click send. It was a lot of luck, though.


It took him about an hour from the first weak transaction to the exploit.  And there was no information on the net at that time.
I think this was not directed, see reason (3) above, but pure unbelievable luck.  (It is not luck that he created the same address as someone else - that would have happened often enough that night - but it is luck that someone put the unbelievable sum of 99.989 BTC on just this address).


Blockchain.info promised to refund all users (I don't know if this particular case has been resolved by now, though).  They admitted that it was their fault.  The problem has been solved.  Of course, the warning "use it at your own risk" still applies.  It probably applies for every bitcoin client.  I'm not saying something similar cannot happen again.


A sequence length of 256 is not sufficient :)   I went more than 10 times further and even then I missed a few values that I added later.
But 256 would have been enough to find half of the money if you also attacked the signatures.


BTW, 208 is the address 1LDpUmrwVKSFyXy2czE423dH8yd4K9R9WW that was emptied first.

Your guess that it was not a bot is probably right, but you are forgetting that in order for the thief to generate the same private keys means he is also Blockchain.info user and they know who he is. Nobody who was not using their wallet had no chance of hitting those keys accidentally. The coins still sit there unspent:
https://blockchain.info/tx/68e250811c2ae572e79811960909b5b9f418d2c977f6ac50226748e3cb808a2a (https://blockchain.info/tx/68e250811c2ae572e79811960909b5b9f418d2c977f6ac50226748e3cb808a2a)
and the thief will have to return them to rightful owners in order to avoid being prosecuted, if he can avoid it at all since his actions are quite fishy.

The thief may be a BCI user, but it would be very stupid of him to use an address that BCI can associate to his person.  He could easily have generated an address with any other software, and issued the transactions without using BCI.

Unless he did first 5.9 BTC transfer within BCI, without thinking.

There are other possibilities, I wonder:

1. The thief may have been scanning the blockchain, like @johoe, looking for weaknesses from the previous (non-BCI) bugs;

2. The BCI programmer introduced the bug on purpose, making it seem an accidental oversight; and then started scanning the queues and/or blockchains for compromised txs.

3. The thief stole the programmer's password at Github and uploaded the bug himself.  (Perhaps he works at github.)

4. The thief hacked into the programmer's computer and introduced the bug on his working copy, which the programmer eventually committed.

Has BCI excluded the last 2-3 possibilities above?

The thief used Blockchain.info to transfer the money to 1M77f...  The transactions have weak signatures.
I guess the address 1M77f is some address he had with a different wallet.  The transactions sending the money further were not relayed by Blockchain.info.

Maybe he used TOR to access Blockchain.info, or maybe they already have his IP address, but prosecution would take some time, especially if he is from a different country.

I think my explanation fits Occam's Razor best.   If someone uses the buggy version of Blockchain.info wallet and creates a new address, the chance is 40 % that he hits an address that was already used, so this part is not unlikely.  The only thing that seems strange is the large amount.  But unless you want to accuse the original owner of the 99.9 BTC that he had staged this to trick Blockchain.info into reimbursing him, you have to assume that this was chance.  I don't think it was staged.

What's happening on blockchain.info?

Lots of large transactions, loads going into this address -
1HWuTMEpRT8vUVLJ4C6Bkb28wwH3GvZkoX

It's almost like somebody is sweeping wallets running down in wallet balance.

I'm watching it go from eg - 63.87553 BTC
to 63.65544 BTC
to 63.4323 BTC

I've just watched it go from 63 to 29.

It's going down all the way numerically.

Very strange.

Edit - Still going - 23.4566 now
Ticking down slowly.


That address - 716 transactions

Total Received   267.74962352 BTC   

Final Balance   83.73226988 BTC   


..................

This is insane, the total received is flying up on this address

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

The BCI page is quite misleading and confuses people all the time, it seems.

The "Total received" field displayed by BCI is a pretty useless number, it is just the sum of all inputs to that address, including "change-back" amounts sent from that address to itself. So it only increases.  The meaningful number is the "Balance", just below it, which in this case is now decreasing.

That 1HWu address once collected many small payments from many sources, with some transactions with dozens of inputs; e.g. https://blockchain.info/tx/c8b71a3f0594a62b66caed2d18729264d65395645dd75a1fefab5c4f49687f4f on  2014-12-21 05:21:55  The inputs did not seem to be in any particular order.  

After that, it has been sending off small payments to many other addresses, e.g. 0.02539274 BTC to 1KeyvxgehPATPnnKYYb4ZckyXCHNzc5PgM, one by one.

The owner of that 1HWu address processes each payment by taking the last input to 1HWu (say, 40.93936457 BTC), sending the small amount to the required address (say, 0.02539274 BTC to 1Keyv) and sending the change (40.91387183 BTC) back to 1HWu.  Thus the "total received" keeps increasing, and each increment is the address balance, which is decreasing.

Ahhh ok.

Thanks

Reading this thread, I imagine that one infographic with a picture of the sun talking about the number of bitcoin addresses could not be generated because of the laws of thermal dynamics or something.

I imagine a special parody of that with some picture of something that involves roughly 256 of something, and an info graphic talking about how fast 256 addresses could be picked.

Then paste a BC.i logo on it or something.

Someone call?

https://i.imgur.com/IL6PV5E.jpg

Priceless!

I have funds on an old key that should be gone but I just looked and funds are there.
I used it during the time this was an issue with blockchain.info

I want to move it, but it is brainwallet.
When I travel, my preson things and papers get taken sometimes, looked at and copy, but I use bitcoin brainwallet to keep money.

Best idea for me would be multisignature wallet with new keys, but how?
I have offline thumbdrive, tails with truecrypt, but if taken, then money is gone so that will not work.

Would like to know of multisig wallet where I make keys and able with sign when needed, but not store them anywhere even encrypted.
Is this a thing?

Thanks to you!

Hey Johoe, would you consider publishing a tipping address in this thread, so people can send you tips?

I think the btc address is in his signature :

@vivalibre: if your address still has money in it, then it was not exposed by this bug ;)
I'm sure that I have found all transactions with R values that were vulnerable due to the bc.i bug.
The only vulnerable addresses I may have missed are *new* weak addresses that didn't have money in it on Wednesday last week (when I did a complete search).  A few of these still pop up. Also there are still a few transactions from the buggy version; last night there were two of them.

1Wo2SJhHbAXYGhQPv4BT7acMvdA5Rmo8i
1Bcch6KBW9P88JgCo7WUkC9dYnnTuotLhc

The first address shows that there is a bot that immediately breaks the key and sweeps the address.  It's not clear whether it used the repeated R value or broke the RNG, both would be possible here.

johoe can we start using bc.i again now?

Are their issues resolved?

Has BCI given any explanation about what went wrong with the humanware?  Did the programmer violate any internal protocols by updating the patch without checking it? What are they doing to prevent similar problems in the future?

This particular issue is resolved.  The few bad transactions can be explained by people keeping a browser tab open for over a week. Make sure you reload the page. If you created any new address since Dec. 7 that you didn't use so far, you should archive it and never use it, just to be sure.

I'm reluctant to say whether Blockchain's MyWallet is safe or unsafe to use now.  This problem may have been a glitch or it may have revealed a bigger problem with their current development scheme.  I would not recommend storing larger sums in this wallet.


Sorry, I don't know why the patch went through without enough checking.  I don't know their protocols, so I cannot comment on this.

There's a single developer, no controls, no testing.

Single developer ? How do you know ? They are running a million dollar business !!!

Thanks for pointing out what I had overlooked! Not much there yet. Hopefully Blockchain.info tipped him well!

More than one according to: https://blockchain.info/about

No, Ben Reeves is the only person who regularly commits any code and looks to be doing it with no peer review. There's no way you can pretend the change that caused this was done with any oversight by anybody. It can't be attributed to mismanagement because well, he is management. He's the guy who started the website, and miraculously the one who caused the 900 BTC loss here as well.

Oh no, scapegoat is found. This poor guy gonna be lynched. :P

Of all thefts and errors that have occurred with Bitcoin, bc.i holds the #1 spot in theft related issues.

Not by a long shot, Mt. Gox is certainly #1....

And at least bc.i is doing what they can to make it right. It was a mistake, and they are fixing it.

Theft under BTC 1000 doesn't get you into the first 30:
https://bitcointalk.org/index.php?topic=83794.0 (https://bitcointalk.org/index.php?topic=83794.0)

BC.i is still to small to make it to the list.

This wasn't about number of bitcoins lost, but number of people who lost coins one way or another.

They were lucky johoe saved them. It wouldve been over 1000BTC if he was not here to sweep.
Technically, the number lost temporarily is above 1000BTC, so it should get in.

Other then Bc.i who lost coins? I believe they were all returned..

Uh no there are at least a handful of bigger thefts that occurred far before this.  ::)

Not only johoe actually.

I'm the security researched who "caused" all of this by reporting a related bug to blockchain.info, which is why they were touching this critical code in the first place. The broken changes (there were multiple, only one is public knowledge) was pushed into production at midnight on Sunday in the UK. I caught the change and was able to get an emergency message to them in order to get them to pull the plug. Had I not had a script watching for changes like this on their site (previous experience has shown they love pushing broken code and then hiding it in git), it might have been a full 8 hours of sleep later that they could have taken down the website. Unsung hero and all that, but people would have lost a lot more money had it not been for that.

Their RNG was broken at least 4 times before this incident as well, it just didn't get any publicity.

So don't go go patting them on the back for their upstanding security, there's still piles of broken shit I've responsibly reported they haven't patched yet.

How many people lost coins in this? Weren't they refunded? Even if they weren't , look how many people lost BTC and how much in fresh thefts like MintPal. By any criteria BC.i is very small, far away from #1 place.

Thank you too.

Have they offered to hire you as a consultant or on a bounty to keep checking for bugs?

No. Their response to responsible disclosure is deeply belittling.

https://i.imgur.com/z8mW9DJ.png




• You have to nag them to even pay out. Some of the reports I have made could have been leveraged to steal millions of dollars worth of Bitcoin directly from their users, such as a plaintext websocket fallback in the wallet communication (https://github.com/blockchain/My-Wallet/commit/98d48a0b5765c6cb42f10c3d07f8b33bef6c5404), SSL not being enforced at all (https://github.com/blockchain/Checksum/commit/0360876d89fe5cabb2c1d9457d896596546a2c27), HSTS not being enforced (https://github.com/blockchain/Checksum/commit/3aac180d1f6ab970c02d70cabdd5d3fd2254a3a4), and a logical bypass for their Tor exit node blocking which amplified MITM attacks. The bounty for these bugs was lumped together at 1.9 BTC total, which I found to be astonishing low given their profile and the probable impact.

• Their security "team" does not know how to use GPG properly, when reporting an insanely critical bug that could still result in the thefts of Bitcoin they responded to a GPG encrypted email in plaintext acknowledging and quoting the security sensitive information.

• High risk bugs that affect the integrity of their service are told to be in scope, partially fixed, encouragement given and then all further reports are ignored for weeks. As it currently stands, the statement that if you use their browser extension or application you are safe from remote attack is completely false.

It is for these reasons I will not be attempting to responsibly disclose bugs to blockchain.info in the future, and I do not suggest other researchers attempt it either.

Next time you should exploit a vulnerability, remove the coins and make it public. It will let you collect a good bounty, increase your profile and get hired as a consultant by some company and expose blockchain which will keep the public warned about using it.

You should not stop looking for vulnerability, youre doing a good service to Bitcoin and the general user who is unaware of Blockchain.info's incompetence.

That would be gray hat. I am white hat.

I had the opportunity to take all of the money johoe did significantly before he even realized it was an issue. It wasn't my place to go saving anybodies coins, it was if anybodies it was blockchain.info's. I don't know the legality of what joehoe did, as far as I could justify in my head at the time even though it was a "good" act, it would still be breaking my countries law. During the event I asked blockchain.info for permission to sweep the money and return it to the company, but they didn't respond in time.


Responsibly reporting even ridiculously critical bugs isn't financially sensible for me with this company.



You would do well to look at potential for disaster. Blockchain.info likely holds high double digit percentages of all Bitcoin in existence. It's possible they own some of the most valuable servers in the world as unlike an exchange they can't use a cold/hot storage system. It's all hot, all internet connected, all the time.

You should ask them for a proper bounty and if they refuse or dont respond report the vulnerability in public. I dont think it will count as blackmail, youre not sure they are competent enough to handle it so you posted here where others can check and suggest fixes.

Once it happens, Blockchain wont be so careless again, but then they were about to lose 1000BTC so if they have not become wiser now they will never be.

johoe says he got a reasonable reward.

You should report any vulnerability here, it will at least get you known and may get you contract with other firms.

Full disclosure gets the job done but it doesn't pay my bills.

Responsible disclosure pays my bills, if it's anybody other than blockchain.info.

It also leaves you with no gf ;D (just realised what the username means)

It will make you known and get you hired. There are a lot of start ups running various types of services which use some kind of online wallet and they may be interested in you if you show value.

Are you sure that a persons like johoe or nogf are interested in bitcoin-related startups ?  ;D

Just realised 'yo hoe' too ;D

They will be interested in the money provided by the start ups to get the hoe or gf :)

Are you sure that bitcoin-related startups will be able to pay salary on a distance of several months?
(My point of view: no)

But when the first reused R values appear, everybody knows that the RNG is flawed anyway. And then fixed RNG code does not help you much to protect transactions that were created with the flawed RNG. Let alone the whole problem of users and their browsers' cache, still executing the broken code.

You can't justify stealing a car because "it was going to be stolen anyway".


If you had $30M USD in your pocket and $400,000 a month in revenue resting entirely on your security, no doubt you'd be making that your first priority.

That car IMO has in that case become more like a wallet you forgot on a bench in the park. I, as the owner of the car/wallet would appreciate it, if somebody takes it in to safe-keep and leaves a message at the location they took it, how to contact them. Sort of what johoe did.



Also, by posting that there are more flaws to be found at bc.i you just gave the black hats a motivational boost.

Oh really how did you make that conclusion when mtgox had over several hundred thousand accounts and then went belly up?

Your assertion that it is the #1 theft in number of affected people is so far off.

Please do your research before talking.

Merry Christmas! ;D

There's no method of doing that in Bitcoin.


There's existing incentive of being able to steal millions of dollars worth of Bitcoin. Do you really think some terse comments confirming that there are issues will make even the slightest difference? It's very much public knowledge that there's huge problems with their management of security, else this thread wouldn't be 20 pages long and I wouldn't be posting here.

Of course there is. The blockchain is a public ledger. Sweeping coins to an address and then posting about it and the address is exactly that. The word will spread quick enough, as was shown in johoe's case.



Yes, I think it makes a difference. This thread is about the R values. You claim that there are more flaws to be found. This could be motivation to poke around some more.

Not everybody reads this little pit on the side of the internet. Not everybody speaks English. Unless it's a very high profile event "saving" someones money will just be theft with no positive identification. Especially in the cases here, the private key was exposed so it could never be proved who owned it in the first place.



Lay off playing the concerned. There's a balance that needs to be struck no matter how you look at it. If people don't voice concern about the security practice of a company, there's an assumption that everything is just fine. I've given no information that could aid anybody in finding vulnerabilities in their code.

This is important.
Please refrain from giving a step by step instruction on how to hack people's addresses.

I highly respect what johoe did but I think he got carried away with his new 'fame' by telling everybody how he did it.
Not cool.

There's somewhat of a difference with this case, in that he was explaining things a lot of us knew about already. Due to the way this particular event played out all of those private keys are compromised and that's the end of it. There's no further exploitation to be done, no further thefts, no further damage. If nothing else he raised awareness for RFC6979 signatures which mitigate this particular problem entirely.

In general there's little value to doing full disclosure. It's a net loss for the reporter (no bounty payout), for the users (they could be negatively affected) and for the company (that has to deal with the fall out). However, in some cases it's necessary to act in that way in order to get things fixed. If a company is being obtuse, lying, or otherwise not fulfilling their obligations to their customer then there's really no choice.

^^^^

Fair enough nogf.

You guys are so tech savvy, very impressive tbh.

So, this:


But then also this:


 ???

It went from here to various different news / social media sites without johoe having to lift a finger.

But johoe did not steal anything, he just picked it up. There is no perfect real world analogy, but this one makes more sense than yours.

If you start using a service to store your money, you better have at least one common language with the service provider.

Full disclosure is still good, because it will wipe bad service providers from the market and teach careless users a lesson. And the reporter's greatest asset is not some change for reward, but great achievements in his vita.

Companies have to die at some point, and some users unfortunately have to learn their responsibilities the hard way.

There's a huge difference between a general fact "their security practice is poor" and a statement like "some user stole $50 it might be yours". One can be widely reported, one generally will not.

Interesting, so how did you detect that there was a serious problem?  Just by code inspection, or did you see a clash on randomly created addresses?

This time it was special. This was the first time they created the same r value more than once. And there were 1000 repeated values in the few hours it was online.



I'm not sure about the legality, but it was the only way to save the money.  I didn't break into other computers; I just took the public ledger and extracted the private keys from that.  Usually, if there is a problem with repeated R values, it is exploited within a few hours.  In this case it took a bit more than 24 hours (https://blockchain.info/de/tx/68c78ee3fbecfd5569a599eaf668ab86b6b6e6d2e6da55c573df100ddfc6d6e5).

I wonder why you didn't sweep the remaining coins that required to break the RNG.  When I did this after six days, I was astonished how much money there still was on these addresses.


I think, I never gave a step by step instruction of how to break an address.  You are probably referring to the posting how to break a particular address using a particular chain of R values and other addresses.  That description showed how I broke one particular key, but that key didn't have any money anyway.  I didn't include the details, or any of the private keys.  Of course, you can look up the details at Wikipedia.  Or you can find the other step-by-step instructions on the web. The knowledge that it is possible to follow R values over several addresses was already out; there was another thread (https://bitcointalk.org/index.php?topic=876149.0) that started two weeks earlier.  Also my posting was at a time when there were already bots sweeping the addresses when they were exploited.  I tried to keep the details of the RNG secret as long as possible.

Sorry for my ignorance, but has this issue been resolved on BC.I's end?

Yes, there haven't been any bad transactions for a week now.

There are still people paying to addresses that were exposed by the bug or that were created by the buggy random number generator, but there is nothing BC.I can do about this.

Edit: I should add that bc.i claimed to fix this bug within a few hours.  There is no way to prove this from my end, but the logs support this as more than 75% of the bad transactions occurred during a few hours.  

BC.I has changed to RFC 6979, now.  Thus, the signatures do not depend on the random number generator anymore.

johoe: As a sidestep  to this, to me it looks like you "found" these bitcoins and returned them to BC.info. In here Finland there is a law that ensures some 10% of findings to the finder. Hope you got your share for doing these people a service, that was quite a feat!

The issue was known from a long time back, so why did a company like Blockchain which handles huge amounts of BTC failed to correct it? Its a very serious lax, and the users should be educated to keep BTC there only when necessary. Many use Blockchain as a primary storage wallet.

It sounds like it is somewhat safe to use blockchain.info again.

I would also say this just shows the importance of rigorously testing any new release of any software that in any way controls any kind of money because people may not immediately continue the upgrade cycle after a 2nd release is released to fix any potential problem 

I haven't seen any sign that they have fixed the organizational problem that created the technical problem.

According to other reports, they have a single super-programmer who ships changes without independent review.

If that is true, good luck...

That is probably not a good idea. Regardless of how "good" someone is at their job it is always important to have people check behind workers' work in order to make sure it meets a certain quality standard.

Although it would generally not be a good idea to have one person (or even one team) in charge of such programming, it would still potentially be feasible as long as a completely separate group is able to independently test and audit the code prior to it being released

They have another problem now as they are incorrectly marking transactions as double spend.
Its time people moved on from there, too risky to keep valuables there.

May I request the mods to make this thread sticky ? Because, I think, new people have a lot to learn from this thread.

I'm not sure that people actually have much to learn from it; or at least the lesson most learn isn't the lesson they need to learn.

The problem is that the security of cryptosystems can't be assured by following a checklist. Do this. Don't do that.  Do this.  No finite set of instructions is necessary or sufficient for security.

The real lesson is the serious hard work, challenge, public review, testing, and residual risk there is with writing cryptographic software.  When you fixate on the list you feel like you have control of the security.

There is far too much adhoc cryptographic code being written in this community (and beyond) by people who are not putting in the serious effort to make sure it's done right. No matter how awesome a coder you are, no matter how many lists of things to avoid, if you're going it alone your code will not be secure, if you're just following instructions from the forum your code is not going to be secure, etc. Maybe it will be _mostly_ secure, but mostly isn't really good enough.

Put another way, if this thread is alerting you to the concern here then it's very likely that you are not yet prepared to be writing cryptographic software for large numbers of people.

The problem is that you have to pay for everything.
Free cheese is only in mousetrap.
Free service (bitcoin/blockchain) can not be better than professional one (fiat/banks)

Hard lesson to swallow but ultimately true. It doesn't mean that banks are better than the blockchain, but bank security is certainly better for that simple reason highly paid professionals are doing security for banks, and they've been doing that for a long time. When bitcoin accumulates few decades of safe security practices under the belt things like this will not happen.

It does. Or what the meaning of the word "better" in your language?

Bitcoin will die in three months maximum. May be sooner.

1. Free service like email has done better than the paid physical mail

2. Free service like news websites have done better than the paid news papers

It is about changing business model with technological advancement. I remember an old saying...

"Money can't buy the will power"


https://i.imgur.com/OQ27PFB.jpg