Yes. Got one about 2 hours ago. See text below.


So no specifics but we can infer that they're aware of and acknowledge that phishing is going on.

I submitted a high-priority ticket to their Helpdesk system and linked them to this thread.

I, for one, will not be logging in to CampBX until/unless they provide more information.

Don't get me wrong, they have been a great service in the past for me, no problems ever.

I got it too.

I am really glad that CampBX never had any bank account info, unlike Coinbase.

Looking forward to hearing more info about this as it is revealed, particularly a response from CampBX.

I got mine in the mail a few days ago and am now wearing it. Very happy. Thanks, jwzguy!

Blueseed has always seemed extremely cool to me.

I'm absolutely thrilled to see Blueseed reaching out to the bitcoin community and trying to incorporate bitcoin into their plans.

Best of luck!

Is there a way to get on the waitlist as a "lifestyle business"? Or, just to live there? I found this to be a bit unclear on the website.

Actually, an improvement on the last suggestion.

Determine an acceptable (given technology) rate of growth of the total set of unspent outputs. Every 2 weeks, adjust the number of (new unspent outputs created - previous unspent outputs spent) allowed per block, based on how closely the maximum rate of growth is being tracked.

This makes the size of all unspent outputs a resource that is subject to an economic feedback loop, just as we already have (in theory) with the total size of each block. That minimizes transaction fees without ruling out legitimate transactions that look like dust (micropayments).

Miners could pay users to spend lots of dust outputs, since it allows them to include more unspent outputs (which they can charge for) in their block.

I need to update my suggestion. I have been told on IRC that the real problem is considered to be that unspent transaction outputs have to be stored in every fully validing node's memory. As opposed to the problem being total block chain size.

So my new suggestion is: Set a safe upper limit on the number of transaction outputs per block. Blocks with more outputs would be invalid and rejected by the network.

Advantages: Miners would optimize such that you need to pay a higher fee if you take up more of the unspent outputs in that block. Now, we let economic feedback kick in and we address the problem head on, rather than waiting for it to bite us as bitcoin usage grows and limiting dust transactions is not enough, since it only indirectly solves the problem.

Actually, you could do _both_ - set a safe upper limit on the block size to deal with storage issues and a safe upper limit on unspent outputs per block, too. Then you'd be totally safe.

Why not just decide an acceptable rate of growth for the blockchain per annum (e.g. 10 GB), limit block sizes accordingly, assume all blocks will potentially be completely filled up, and be done with it?

This seems to directly address the fundamental issue (the concern about too much data in the block chain), which we will eventually face anyway if bitcoin is successful.

It should be perfectly fine to do what he's describing as long as you completely close down bitcoin-qt between moving around the wallets. That's what I've been told by developers.


monocolor, if you want to describe why you want to do this, someone may be able to suggest a better way to achieve what you're trying to do. However, I can imagine valid reasons for doing what you're doing.


I think that shouldn't happen, but starting bitcoin-qt with --rescan (on Linux; do whatever is equivalent if you're using some other OS) will likely fix it.

First, thanks for a very informative post.

Now, I want to veer off topic just slightly.

From my point of view, when generating offline wallets, the entire system you use is the trusted computing base. So I wanted to minimize downloading third-party software besides (in my case) a linux distro and bitcoin-qt. Which is already, in my opinion, a very large and not-that-trusted "trusted" computing base. In any given distro, there are thousands of packages, so thousands of upstream projects, and tens to hundreds of package maintainers.

Shouldn't we be worried about this? If not now, perhaps in the future? Couldn't, say, a governmental entity invest the resources needed to compromise this kind of system? Then, they could introduce a bug similar to the following real one posted on the EGD site, for example:


Besides messing with key generation, they could also potentially attack Armory (both on the offline and online clients) to pass information between them. Or they could modify cp such that if you're trying to copy one of several offline wallets to a USB drive, all of them are copied covertly (and then exposed by a malicious cp on the online system).

I'm posting this here because it's in the same vein of paranoia as the rest of this discussion, plus I already have the attention of some smart people and the non-attention of trolls, but perhaps a new thread would be preferable if people have much to say on this besides, "you're crazy" or "go take a look at this prior thread elsewhere".

Well, yes, and no. I mean, if you do strace -o output vim (for example), you will not see /dev/urandom. So, what the output I observed is telling me is (a) /dev/urandom is being used (though as you say, exactly how it's used is unclear); (b) /dev/random is not being used (since it doesn't appear in the trace). Of course, we pretty much highly suspected all this from looking at the OpenSSL code. Anyway, this will provide an easier test for people in the future.


Thanks, this is an extremely helpful clarification. Gmaxwell made very similar points in IRC, but it's helpful to see it all laid out in one place. This explains exactly why the warnings in man 4 random about long-lived GPG/SSL/SSH keys do not apply to long-lived Bitcoin keys, which I didn't quite 100% understand as of my last post (otherwise I would have said it).


I tried that, pretty sure I did it "correctly" (in the sense that I made the obvious changes), and the compile was fine, but there are a bunch of post-compile checks, and while a bunch of them passed just fine, eventually I hit one that did not pass. I think the problem had to do with the test blocking on /dev/random (remember, my machine tends to have very low entropy), and I think the blocking somehow triggered an error - perhaps some kind of timeout. I didn't really investigate. If someone bothers to get it working, hopefully they'll share here in this thread.

Sorry for my delay in responding. I'm fairly satisfied on this topic, but I'm going to give my final "conclusions" and "findings" for the sake of posterity.

First, there is a simple test to see if bitcoin-qt and openssl are using /dev/urandom or not on a particular machine with pretty high certainty:


On my system (and probably on practically all modern linux desktops), you will find a read of /dev/urandom in that trace, meaning yes, /dev/urandom is being used.

Interestingly enough, man 4 random has some warnings about NOT using /dev/urandom for certain OTHER (non-bitcoin) cryptographic purposes (obviously, the man page predates bitcoin)...


Also:


I checked out gnupg for the sake of comparison, and it's using /dev/random, which is in accordance with the above advice.

So, from someone who knows enough about cryptography to know that I don't know anything about cryptography  , all this is troubling.

However, gmaxwell has repeatedly (on multiple occasions) assured me on IRC that he knows enough about cryptography to know that it's just not something we should be worried about. Even after I specifically brought up the above warnings. For example:


It would be nice (though probably suboptimal for other reasons) if bitcoin and openssl had opted to take the route that would be obviously safe to people who are not crypto experts, allowing us to avoid this whole conversation altogether, and allowing people like me to not have to think about how much we "trust" the bitcoin and openssl devs on this. Of course, I do trust those people, but I also lock my doors at night, even though I trust that I live in a safe enough place to not need to.

That's not actually a request or complaint; actually relying on /dev/random would (a) almost certainly be an issue to bring up with openssl, not the bitcoin devs; and (b) would have other major downsides.

Anyway, moving on to more practical matters, here is something (below) that other paranoid people like me can actually do about the situation. (Note that simply simlinking /dev/urandom to /dev/random just caused errors for me, and the post-compile checks for openssl failed for me when I tried to change the openssl code   )

I found on my desktop machine, my entropy is often in the low hundreds, which by all accounts is abnormal. I don't know why - perhaps part of it is that I use a very simply window manager, don't have a lot of stuff running, and hardly ever use the mouse. Probably nothing to be worried about, but it's clearly abnormal, so I was a bit worried.

However, when I went to actually generate my offline wallets, I did use the mouse a lot (plus I was using a different distro than normal), and there was plenty of entropy. How do I know? I wrote a program that checks the entropy in a loop and exits with a complaint if it falls below a user-provided threshhold. The program is provided below for anyone who wants it.

Thanks for your feedback, but I'm aware of all that, and it's just not what I'm asking about.

I don't have any special or new hardware (so, no TPM or Ivy Bridge or later CPU). I don't want to reveal exactly my whole software setup. Not that I have _that_ many bitcoins, but revealing exactly which version of what software I'm running seems to be a very poor security practice.

Regardless of exactly what is going on below the covers, shouldn't OpenSSL be pulling either from /dev/random or /dev/urandom? If so, what's going on beneath the covers doesn't matter, because /dev/random blocks where there is insufficient entropy, and with /dev/urandom, I can check and see how much entropy there is. That's exactly why those things are there - so that there is a standard way to make sure you have enough entropy, regardless of exactly what you are doing.

So, frankly, if bitcoin (and ultimately OpenSSL) are not using one of those two mechanisms, I would find that puzzling. And I would be curious to find out (a) why not; and (b) what is the standard procedure for someone who is not an actual OpenSSL developer to make sure their applications are getting enough entropy.

I somewhat suspect that either bitcoin or OpenSSL does make sure there is enough entropy, and the right person who can confirm that just hasn't shown up. If it doesn't, that would be a good feature to have (and arguably a bug to not have it). In other words, IMHO, the standard client should guarantee that the addresses it generates are always good addresses and you can't predict the next private key based on knowing other private keys generated around the same time on the same platform (modulo the phenomenally unlikely chance of having a collision). And I bet it does, it's just not been publicly documented yet (that I have found).

For example, deepceleron stated "rand_getbytes returns an error if there is insufficient entropy pool." That is almost good enough for me, but I wasn't able to find that function in either OpenSSL or bitcoin, and even if I did, I personally would like someone to reassure me that that function (or something equivalent) is actually going to be executed on a standard Linux setup.

Anyway, AlphaWolf, thanks very much for taking the time to help me, and hopefully you, deepceleron, or someone else can further enlighten me.

Thanks. I really appreciate the help. I couldn't find rand_getbytes, grepping through both the bitcoin source and the openssl source, though. Did you misremember the function name, perhaps?

As long as there is some verification (either in bitcoin or whatever part of openssl that bitcoin uses) that there is sufficient entropy before generating the first address in a new wallet, that would definitely put my concerns to rest.

I would rather defer to experts than look at crypto code and trust my own shaky assumptions about which code paths are being executed and under what circumstances.

I didn't say anything about disassembly. Please read what I wrote instead of ignoring it and saying ignorant things and cluttering up the thread.

And I didn't ask for your opinion about OpenSSL, I asked for specific information (which you have ignored).

Thanks.

I'm having a hard time believing that the answer is that non-straightforward. I mean, probably it uses /dev/urandom except in some weird circumstances that can be ruled out given certain basic assumptions (e.g., standard Linux on x86 without any special-purpose entropy-producing hardware). But yeah, this is just my intuition, I can't actually give evidence for this.

I guess one way to find out (for my particular instance) would be to do some kind of tracing of the actual binary I have to see what files it opens. Assuming it does use /dev/urandom, do you have any idea of how much entropy actually needs to be accumulated before creating another wallet?

And I don't suppose there is any easy way to guarantee some other process doesn't suck up the entropy right before bitcoin uses it?

Honestly, it seems like /dev/random would be better for my purposes, since it'll block until it gets enough entropy. I wonder if I can symlink /dev/urandom to /dev/random or something crazy like that.

Nobody has answered my question. Thanks anyway for those who said intelligent things. However, if someone can provide an actual answer, I'd appreciate it.

It's not true that OpenSSL uses /dev/random, or at least, that's a misleading thing to say.


[1] http://www.openssl.org/support/faq.html

So, again, my question is, can someone who knows about the client code confirm that it's ultimately using /dev/urandom?

If so, is making sure /proc/sys/kernel/random/entropy_avail is a high enough number (and what number is "high enough"?) sufficient?

Personally, I think I know the answers to these things, but I'm not certain, so I wanted to see if someone who knows can back me up. I tried looking at the code before I started this thread, but the answer wasn't obvious, and I'd rather avoid sinking hours into reading the code more carefully.

I want to create a bunch of fresh, empty wallets with the standard client. (Why? Having multiple wallets is something I want for security reasons, and this is just a relatively hassle-free way to do it.)

The most convenient way for me to do this is using a Linux live distro, but I'm worried there my not be enough entropy on such a system.

Can I just check /proc/sys/kernel/random/entropy_avail and make sure this number is above 200? (I'm getting this advice from [1]).

In other words, does the client (or the libraries it's using) actually use /dev/urandom, and if so, what is "enough" entropy?

Thanks.

[1] http://major.io/2007/07/01/check-available-entropy-in-linux/