Agreed.  My current understanding of PBKDF2 is that there's a near symmetry between the functions of the mnemonic and of the passphrase.  The main difference seems to be with intent, where the mnemonic is expected to contain more entropy while the passphrase is easier to remember.

At the time I was referring to the use of "plausible deniability" in BIP0039 (which focuses only on the passphrase) and certainly could have made that clearer.


I didn't understand this but it seems interesting.  Could you elaborate please?

It seems to me that, without both the mnemonic and the password, any attempt to prove a link between a mnemonic (resp. password) and a seed (perhaps a BIP0032 master key) would practically require brute-forcing the password (resp. mnemonic).  In both cases I believe that, as DeathAndTaxes suggests, one or several dummy keys, potentially with some activity, could be accommodated and even fully revealed without weakening this brute-forcing requirement.

More precisely.  People in the bitcoin community are more cynical than you expected.

As a long-standing bitcoiner, I find non-bitcoiners to be rather cavalier and highly gullible in general.  There's a big difference between activity in the Bitcoin economy (where you have real freedom and responsibility) and activity in the mainstream economies (where you're effectively a child being protected by your government).  This contrast is felt by many hapless newbies who show no fear (just as puffins showed no fear of human colonists) and fall prey to even highly suspicious scams.

There are plenty of very trusting people out there but they don't have enough freedom to easily hurt themselves and are generally not attracted to such freedom.  Such people will have no interest in Bitcoin until and unless it is blessed and made child-safe for them by their government.

Please take care in any Bitcoin business dealings.

Well done Rassah!  Have fun at the Consumer Fair.

Wait.  So I should make a backup in case my head gets destroyed?

Hmm... It seems Bitcoin is riskier than I thought.

This is indeed a valid definition of "inefficiency".  However, you are the one that judiciously introduced the term "waste" into your description of the mining process.  Your assertion that Bitcoin mining is inefficient is simply built upon your assertion that Bitcoin mining is wasteful.

Also, I don't understand the meaning of "actually do the work" here.  Are you suggesting, for example in the case of block #300001 appearing 19 minutes after block #300000, that the block winner did 19 minutes of actual work?  Surely all but one of the trillions of hashes performed by the block winner in this period were every bit as wasted as the unsuccessful hashes of all block losers.  Surely the block winners unsuccessful hashes were every bit as wasted as the unsuccessful hashes they performed before block #300000 (when they were themselves a block loser).

Ah, yes, I missed that at first too.  The masses of poorly thought-out posts on this forum has encouraged me into the bad habit of skim reading everything not written by a small white-list of known good posters.

Sure.  If the RNG is flawed then the chances of finding a collision are improved.  I agree it's most likely that this newkey function is used under the hood when people create new addresses in their blockchain.info wallets so there should be plenty of addresses containing funds to collide with.

What the probability of collision is is open to speculation.  Theoretically, anything from [number of existing addresses] / 2¹⁶⁰ up to 1 is possible and, absent the code, we only really have the fact that no-one's found a collision so far to guide us.


I agree that the keys would not be repeated and the addresses would not be random.  However, the RIPEMD-160 step (assuming RIPEMD-160 itself is not badly flawed) ensures that the addresses will be seemingly random and address collisions will not be practically predictable (precisely as Bitcoin mining gives rise to unpredictable block generation times).

Awesome!  I've been looking everywhere for an exchange aspiring to provide an experience on par with the major banks.

Do you have plans to randomly freeze accounts due to "suspicious activity" where the details are withheld from the account holders for the purposes of "security and fraud-prevention"?

To clarify: "A small price to pay for not getting goxxed, vircurexed, GBLed, and many others." is an opinion.  One could just as easily consider the price too high.

Certainly scammers will scam, just as regulators will regulate, but such observations do not magically render the subjective objective.

That's your opinion.  Can you not be content to patronise those exchanges which actively invite proof of solvency and insurance?  Must you work towards forcing your model of the ideal exchange on everyone else?


If people have trust issues with decentralised exchanges or completely unregulated exchanges then they will favour the exchanges which provide a safer, highly regulated environment.  If many people feel this way then such exchanges will thrive, while the sketchy exchanges will remain illiquid and collapse regularly.

All government regulations achieve here is to remove some freedom from the people.  People are being denied the freedom to experiment.  This is defended as: "The people should not be allowed to experiment and fail" but what is left unsaid is: "The people should not be allowed to experiment and succeed".

If you feel that when you know better than other people how they should handle their money and further that you have a moral duty to control these people for their own good then we're opposed in principle and will likely never agree.

My mistake.  A more careful look revealed that indeed you are checking for any addresses which have ever received funds.


I don't know the details of the sources of random used by blockchain.info's newkey.  While I agree that there is the possibility of a flaw in the RNG leading to unexpected long-term behaviour of the script, I maintain that the best way of resolving this potential flaw is to throw out the RNG altogether.  A collision generator has no need for anything random.

Yes, all this speculation takes RIPEMD-160 into account.  It is because of the RIPEMD-160 that a collision is going to look like having two different private/public keypairs which correspond to the same address.


Cool.  Note that a collider doesn't need high-quality randomness for each address.  Just working through all the private keys in order from 1 to 115792089237316195423570985008687907852837564279074904382605163141518161494336 would be fine (yes, there are quite a lot of different private keys).

Anyway.  At 320 addresses per hour and assuming all else constant, you should be finding an address collision once every 121 billion trillion trillion years on average (similar to the way a new block is generated once every 10 minutes on average so expect some variance).  Notice that you'd actually be generating a collision on average once every 7.8 billion trillion trillion years but because your code checks collisions by checking for a balance and most addresses in the blockchain have a balance of 0 you'll be missing a lot.

I feel it's worth comparing this to Bitcoin block generation.  A script which generates 320 hashes per second will find a block on average once every 72 trillion years.  Given that many CPUs are capable of hashing 10 000 times faster and that an address with non-zero balance contains about 3.2 BTC (compared with the average block payout of about 25 BTC) we see that anyone looking to run this code for profit would be about 100 trillion trillion times better off just CPU mining Bitcoin.

Just to clarify: there's a wide margin between finding an address collision in this fashion and breaking Bitcoin*.  The latter would at bare minimum require something like the hypothetical futuristic Mount Everest machine I described above.

The cluster could probably be used to solve chess and maybe even run Crysis but it will not break Bitcoin.

*I'm assuming there is no subtle bug which would cause problems should two outputs at the same address be moved simultaneously using different keys.

Hmm...  Maybe about 30 exajoules (roughly 8000 terrawatt hours).  This is assuming we can be clever about how matching pairs are checked for and most of the drives can be powered down for most of the year.

Switching off both China and the US and diverting the power to the cluster should be sufficient.

I understood Grumpster to be asking about colliding with one of the currently existing addresses rather generating two addresses which collide with one another.  If we're just looking for two distinct private keys which yield the same address then indeed the Birthday Problem applies.  The average number of addresses you'd need to generate to find such a beast is approximately 1.5 trillion trillion (a little bit more than square_root(2¹⁶⁰)).

This problem is far closer to tractable.  All we'd need is about 2 billion gaming rigs running for a year, each with about 20 000 terrabytes of storage.

With a few basic cryptographic assumptions, the chance of a single randomly (uniformly) generated Bitcoin address colliding with an existing address is simply: [number of existent addresses] / 2¹⁶⁰.

At the moment of writing (block #348386), there are 66 214 306 distinct addresses recorded in the blockchain (93.5% of which are empty by the way).  This yields a probability of about 4.5 * 10^-41 (about 1 in 22 000 trillion trillion trillion).


Not to my knowledge.


Such hardware would need to be able to generate close to 2¹⁶⁰ / [number of existent addresses].

A decent CPU might manage to generate 500 000 addresses per second.  Working with a companion GPU well-suited to the task and you might be looking at 20 million addresses per second.

"What about ASICs?" I hear you ask.  Well, let us suppose that you could design a machine a billion times faster than this for the same mass of hardware and power consumption.  We'll assume the machine can also check addresses against the relatively tiny pre-set list of existing ones as fast as the new ones are generated.

A cluster of these machines capable of "getting close" (lets say having a fair chance of generating a collision within a year) will draw about as much power as consumed in all other human activities combined and weigh about as much as Mount Everest.

Yes, just to clarify: I mean to recommend running a full node as a hobby in and of itself, not to recommend running a full node as part of a hobbyist mining operation.

Also, there's no need to diminish the act of running a full node.  This helps much more than mining.

As Cryddit says, we don't know for sure.  Of all the possibilities though, I strongly favour the idea that Satoshi was simply telling the truth.


Given the design and code at the time I have no good reason to doubt this.

Sure.  Why not?  You'd be doing no more harm than people that spend their spare cycles hunting for primes, folding proteins, or searching for extra-terrestrial life.  Just be aware that if you're mining bitcoins with a CPU or even a GPU then you're basically just running an unrelated stress test for all the good you're doing.

If you're looking for a hobby in maintaining a machine to support the Bitcoin network then I highly recommend running a full node.

For what it is worth: while drafting an electronic mail item before my break-fast this morning I used the term "block chain".