Having some new things available does not necessarily obviate older or other things. Interestingly, right now many of the largest universities in the world (in terms of enrollment) are in fact Open, distance-learning institutions.

I think one needs all of the above (including some physical schools, physical books, physical industry, etc.) We need the "virtual" equivalents, too; each complements the other. The same goes for instruction, in fact: as you note there is no substitute for talking to an actual (competent) instructor, but you also need to spend an equal number of hours by yourself reading / doing homework.

Consultation (research projects, industry, academic): $500 / day (bitcoin equivalent)

bump for finals!

Why not adapt existing solutions for this? Plenty of distributed key-value storage software is freely available. Is there some special requirement in your case that is not satisfied?

Nothing (except resource limits) stopping you from running multiple protocols over the same pipe...

As for Gnutella, you can fit a power law with cut-off to the degree distribution but I do not recall how statistically significant it is (p-value).

There was a similar thread not long ago, in which the poster initially expressed mistrust in using the PRNGs provided by Linux and MS Windows to generate private keys. As in your case, it turned out that the concern was not some supposed design flaw in the cryptographic PRNG, but rather that it takes time for a freshly-installed system to seed itself with enough initial entropy. One thing you could do is simply to do random things with the mouse and keyboard and wait a while before generating important keys (the OS's estimate of "entropy available" is only a rule of thumb of course, but certainly at the very least that long). Another is to note that on Linux you can write to /dev/random to feed it entropy from an external source, so if you want you can pipe in an image of a lava lamp, radio static, electronic noise from the CPU, etc.

It should be mentioned that the group law/multiplication on an elliptic curve has a simple geometric interpretation: roughly speaking, if you draw any line in the (projective) plane, it will intersect your curve in three points, say P, Q, and R. Then  P + Q + R = 0. See any textbook or Wikipedia for a picture.

All the addresses "exist". You will find it difficult to spend the coins without an associated private key, though.

NB Zeilap's comment. That said, look at https://bitcointalk.org/index.php?topic=133220.0 to see how to string the commands together.

For anyone interested in pursuing this, here is a preliminary exercise:

Devise a method to obtain a "random" sample of steadily-connected Bitcoin nodes (I suggest at the very very least 100) and for each one record the number of connections to the network (this information should be visible in the default client's Debug Window). What can you infer about the distribution of this quantity?

Thanks for the links and comments. A client modified to gather info and statistics, and persuading enough people to run it, seems like the way to go. Schemes to compute accurate statistics for dynamically changing peer-to-peer networks, based on local measurements, have indeed been researched for at least a decade or so, but it seems no one has yet applied them to the Bitcoin network (even if someone had, such results should be independently reproducible).

cf https://en.wikipedia.org/wiki/Mental_poker

Hi aantonop

I assume your kit is meant for "average" users? If so, isn't the software arguably the most delicate component of this? Since I do not see that it has been explicitly mentioned here, your kit should include something like a bootable DVD or USB stick with secure software pre-installed on it, together with easy-to-follow instructions on how to verify the checksum. Also do not forget that since you are booting into a more-or-less known state it is absolutely essential to introduce enough entropy before generating any random numbers, etc.

No harm; on some (most?) systems you can write data to /dev/random for this purpose.

Yes, entropy is supposed to be gathered from multiple independent sources and processed to reseed the generator. As long as there is at least one source that is unpredictable to the attacker you should be OK. Did you read the chapter on the implementation of Fortuna?

Note, if your entire system is compromised, you have other things to worry about than the random-number generator. What a cryptographic PRNG is designed to deal with are cryptographic attacks, like reconstructing its internal state, though I am not sure which attack scenario you are envisioning where you have to worry about such attacks on your RNG but your system isn't otherwise completely owned anyway.

That's it? No keystrokes, mouse movement, etc?

Just use CryptGenRandom. Or, if you do not trust Microsoft, a different OS/implementation; I gave you at least one reference.

Whether you are just generating a couple of keys for your personal experimental use or running a commercial site that needs a secure wallet, the poster did not mean you need to or should rely on external web sites to get random numbers. The point is that you can obtain data from multiple sources (web sites, stock prices, your own hardware/software) and then "distill" the resulting entropy.

So the issue is that you do not trust the PRNG provided by the operating system (/dev/random, CryptGenRandom) even with a truly random entropy source seeding it??

One can use SHA or AES-CBC-MAC or whatever to distill/condition entropy, but... so you do trust the OS-provided CryptGenRandom or /dev/random to gather entropy from electronic thermal noise, OS latency, pictures of lava lamps, but do not trust their conditioning or PRNG? Why use it at all then?

I re-iterate what was said about not "rolling your own", but if you want to implement the PRNG yourself then look up e.g. the Fortuna algorithm in Practical Cryptography. Add a couple of lava lamps and you will be good to go...

I am glad to see you are taking randomness seriously

How many random bits do you need? Unless you are generating many, many keys, the PRNG should not be a bottleneck. There are also hardware-based RNGs.

The order of the base point of secp256k1 is not quite 2^256, as you noticed, but it is so close that generating 256 random bits and throwing away out-of-range values (on the remote chance you ever get one) is not a problem, and that way (after doing all the arithmetic) you will end up with a point uniformly distributed on the curve.

Let's agree that, no matter what goes on inside the mixer, coins go in and later coins come out; what achieves anonymity is the inability to connect inputs with outputs. Therefore small batches and a small latency window will reduce anonymity. Consider the case of a coin sent to the mixer and a coin that comes out 36h later, or a couple of weeks later - could they be connected? Seems better not to set short time limits.

Also do not forget that an attacker will be spamming the server with their transactions, both for DoS and to fill up any small batches. Of course for each "real" input there will be a probability that the mixer adds a dummy input and output. (And of course all communication with the server is encrypted and dummy traffic generated.)

Some crude back-of-the-envelope guesstimation shows that £1 should buy you more than 5 GFLOPS (general purpose) these days, meaning to buy the hardware. There are also operations costs and overhead to keep running; you can get a few GFLOPS per watt or even much more.

How much are you really going to pay? More guesstimation indicates your £1 will buy you a TFLOPS for an hour. But I have no confidence in that unless people chime in with how much they are really paying.

FLOPS on Wikipedia, also "Performance per watt"

There are different clients, though, and many people use online wallets. Just something to keep in mind (eg you would not want the online wallet to know which addresses are yours and therefore link them!) That said, an easy-to-use plugin or standalone application is probably the way to go, sure.


not sure if that fast, don't forget that the batches will be queued up and broadcast in some random order. And it will take time before "a lot of people" are using the service on a regular basis!

I meant secure as in indistinguishability of outputs. You are right, of course.

Not simpler, but having some of the mixing bypass the Bitcoin network completely is potentially more secure.