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. |
|
|
|
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. 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. |
|
|
|
Maybe they don't have weak k? |
|
|
|
If someone would like to review my code, I'd be glad - https://github.com/hhanh00/offlinesig - but it's not easy to get someone to do it. I didn't rewrite a crypto library. I used bouncycastle and provided a generator for k following the RFCxxxx. The only values exchanged are (r, s) and I don't see any other sidechannel since it works offline. I think he meant code revision in general, not just for this single potential bug. You can't just review a Bitcoin wallet by reading it once or twice, it's way too complicated. So better stick with known code that has some user base actually testing it. |
|
|
|
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) |
|
|
|
|
How do you define which chain is valid if no mining is done?
What does "longest chain" even mean if you have no mining?
What does that have to do with 51 % at all?
|
|
|
|
Bitcoin works very similar to cash in a sense that you have bills that are not divisible. In your case you had a 0.715 354 32 BTC bill, among others. Every input you receive is a single bill and if you want to spend parts of it you will get change [1]. Some wallets allow you to spend "unconfirmed change", Multibit does not by default. Thus your 0.715... BTC are esentially gone until the transaction gets its first confirmation. If you take the TX-Id and watch it with a blockchain explorer you will see that there are two outputs. One for the person receiving your coins and one for your change. Until the change is confirmed multibit treats it as it would any other unconfirmed transactions and acts like it has no control over it.
[1] this is done durring the TX, its not like the other person is actually returning anything to you. Another picture is to imagine lumps of gold. Your 0.715... BTC lump of gold has to be melted down in order to be spend partially.
This is exactly what I was saying. |
|
|
|
|
@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.
|
|
|
|
|
I guess it was just the change and you needed some confirmations for your client to recognize that it is yours again.
|
|
|
|
|
@johoe: Did you use the blockchainr tool or make your own?
|
|
|
|
|
You should not do crypto in JS or Java in the first place. In those languages, you do not have control about memory management. For example in JS, you have no control over how and were the browser stores your secret data (keys etc.). There is no way to enforce the physical deletion of private data.
|
|
|
|
|
Leider jetzt erst davon gehört. Beim nächsten Mal komme ich auch!
|
|
|
|
|
I thought about it once again:
Dan, it is not like banks. Even if you end up with large companies managing the block chain, the user has the ECC private keys - which means the user has the power over his money. This empowers him to dump a bank and go to another one in minutes.
It will not be fully decentralized in the current sense, and it may cost some fees. But it's still totally different from the current system, where banks can just burn your money.
|
|
|
|
|
The bitcoin connects - even if detected - is no evidence for a court of law. But it is enough for the investigators to find the physical box with the illegal substance. That box is evidence, especially if they catch it right at the delivery company and know who sent it to whom.
|
|
|
|
The 50% mark is not really a tipping point, as you can still get left behind in many potential attacks. Percentage of network power just means are you ever-more-likely to be able to double-spend while waiting with a chain of length X in the background. The attack is still very, very difficult and reliant upon probability even at 60%, 70%, etc.
Yeah, but what makes me nervous is that someone with that kind of power could lay in wait for an indefinite period of time...spending whatever it takes to remain substantially ahead of the network...waiting for the most opportune time to reveal themselves and completely undermine bitcoin. That could cause a pretty big chaos, but is no real danger of cheating. |
|
|
|
We do, we use make. For our purposes, it works fine if you have a sane build environment.
An environment with uupnp is not sane. |
|
|
|
Do you see any attacks that I haven't thought of?
Would it be in the swap space somewhere unencrypted? Yes, that's true. That should be mentioned. I don't use swap for that reason myself. But some footnotes: - If Bitcoin is implemented properly, it wouldn't store keys in swappable memory. - Swap should be encrypted anyway - but that makes hibernation more difficult. |
|
|
|
Yes, obviously the amount of data you have to store goes up with the number of users. That's not exponential unless you have a very optimistic of Bitcoins future! At some point usage will stabilize and working set storage along with it.
I don't say that it must be a problem, as computer capacities grow exponentially as well. I just wanted to say that pruning does no magic. |
|
|
|
The other attack is the offline attack, where the attacker does not publish his blocks until his chain is at least X blocks longer than the public chain. In this attack, 51% is indeed a tipping point, because once he reaches 51% he is assured that if he waits long enough, he will eventually have enough blocks saved up to perform the chain reversion.
But this attack is so easy to detect that it makes no sense to try it. You mean like everyone would notice if 7 blocks get swapped all at once? Yeah, we would notice, but they would be the correct chain then, so what would we do about it? I didn't say that you can't. You can. But it is obvious. And you needed more computing power than the rest of the net - and can reverse transactions that are just "confirmed". |
|
|
|
Bitcoin doesn't track balances of addresses. That's not how it works.
I know that. But you have to, if you want to prune the chain. You need to store unspent outputs. A transaction doesn't say "spend X coins from address Y". It says "import the value from output N of transaction T using script S". If an address has nothing on it anymore, that's another way of saying there are no unspent outputs containing it. If a new address gets some coins then spends them it can disappear entirely from the pruned chain, such that there's no evidence it ever existed (except in the records of nodes that deliberately choose to not prune).
Yes, but that does not happen. The number of addresses will still go up for a number of reasons, e. g. the increasing number of users and the BTC deflation. |
|
|
|
|
Show Posts
