|
X7
Legendary
Offline
Activity: 1162
Merit: 1009
Let he who is without sin cast the first stone
|
|
December 15, 2014, 05:25:31 PM |
|
this is turning into a cluster fuck
|
For what shall it profit a man, if he shall gain the world, and lose his own soul?
|
|
|
bcearl
|
|
December 15, 2014, 05:26:14 PM |
|
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!
|
Misspelling protects against dictionary attacks NOT
|
|
|
molecular
Donator
Legendary
Offline
Activity: 2772
Merit: 1019
|
|
December 15, 2014, 06:32:42 PM |
|
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
|
PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0 3F39 FC49 2362 F9B7 0769
|
|
|
cr1776
Legendary
Offline
Activity: 4200
Merit: 1312
|
|
December 15, 2014, 06:51:23 PM |
|
...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
Legendary
Offline
Activity: 1778
Merit: 1043
#Free market
|
|
December 15, 2014, 06:54:02 PM |
|
...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
Full Member
Offline
Activity: 164
Merit: 128
Amazing times are coming
|
|
December 15, 2014, 07:30:56 PM |
|
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
Newbie
Offline
Activity: 19
Merit: 0
|
|
December 15, 2014, 07:35:05 PM |
|
|
|
|
|
lontivero
Full Member
Offline
Activity: 164
Merit: 128
Amazing times are coming
|
|
December 15, 2014, 07:55:37 PM |
|
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 (OP)
|
|
December 15, 2014, 08:53:35 PM |
|
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.
|
Donations to 1CF62UFWXiKqFUmgQMUby9DpEW5LXjypU3
|
|
|
bcearl
|
|
December 15, 2014, 10:31:21 PM |
|
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.
|
Misspelling protects against dictionary attacks NOT
|
|
|
JorgeStolfi
|
|
December 16, 2014, 03:04:57 AM |
|
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.
|
Academic interest in bitcoin only. Not owner, not trader, very skeptical of its longterm success.
|
|
|
itod
Legendary
Offline
Activity: 1974
Merit: 1077
^ Will code for Bitcoins
|
|
December 16, 2014, 07:33:08 AM |
|
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.
|
|
|
|
|
JorgeStolfi
|
|
December 16, 2014, 10:43:58 AM |
|
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...
|
Academic interest in bitcoin only. Not owner, not trader, very skeptical of its longterm success.
|
|
|
amaclin
Legendary
Offline
Activity: 1260
Merit: 1019
|
|
December 16, 2014, 10:52:13 AM |
|
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
Legendary
Offline
Activity: 1974
Merit: 1077
^ Will code for Bitcoins
|
|
December 16, 2014, 11:03:46 AM |
|
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
|
|
December 16, 2014, 11:05:55 AM |
|
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.
|
Academic interest in bitcoin only. Not owner, not trader, very skeptical of its longterm success.
|
|
|
amaclin
Legendary
Offline
Activity: 1260
Merit: 1019
|
|
December 16, 2014, 11:18:48 AM |
|
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 (OP)
|
|
December 16, 2014, 12:55:48 PM |
|
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/1MKSWH9pShsLdV54cRLDQ9JKarsjXK4ms5Or did just someone read the security alert and saved his money?
|
Donations to 1CF62UFWXiKqFUmgQMUby9DpEW5LXjypU3
|
|
|
|