Reused R values again

[Mandrik]

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!

[1715691251]

1715691251

[1715691251]

1715691251

[X7]

this is turning into a cluster fuck

[bcearl]

or send it to the same address, i've changed the pass

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

[molecular]

Unfortunately my ssh session timed out and took my script with it  
Have to run it again, it will probably find some more keys.

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.

You can even share a screen between multiple connections

[cr1776]

...or send it to the same address, i've changed the pass

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.

[redsn0w]

...or send it to the same address, i've changed the pass

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.

[lontivero]

people who have been the victim of blockchain.info's incredible incompetence.

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).

[Artemzz]

it doesnt matter now

[lontivero]

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 .

[johoe]

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).

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.

[bcearl]

Testing a random number generator is of course hard.

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.

[JorgeStolfi]

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. 

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.

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. 

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.

[itod]

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.

[amaclin]

... let alone it is impossible because every commit to the code is tracked on the GitHub...

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.

[JorgeStolfi]

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.

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...

[amaclin]

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

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.

[itod]

... let alone it is impossible because every commit to the code is tracked on the GitHub...

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.

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.

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.

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.

[JorgeStolfi]

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

This bug is visible in blockchain since september.

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

[amaclin]

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

[johoe]

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?