2^256 Deep Space Vagabond

[Hash Hyena]

We just wanted to add,

We can have this discussion on another thread soon, we do not want this to hijack DSV's thread. we just wanted to make a quick announcement in a place where interested parties were hanging out. If you feel you have some trolling to do, message it to us for now you can copy/paste it in a few days when we get our own thread up and running. Lets let the OP keep his thread clean and on topic.

[1714033404]

1714033404

[1714033404]

1714033404

[1714033404]

1714033404

[BurtW]

I will use 32 bytes per address (2⁵ bytes per address) in my response.  Storage of addresses will actually take more than that so rounding to 2⁵ is in your favor.  I will also give you binary megabytes, terabytes and petabytes of storage which also works in your favor but makes the math easier.

Or better, just over 1 PB worth of data storage and we managed to nab a few transactions from the blockchain already.

Just an empty claim until you prove it.

1 binary PB = 2⁵⁰, 2⁵⁰ bytes / 2⁵ bytes per address = 2^50-5 = 2⁴⁵ addresses, 2¹⁶⁰/2⁴⁵ = 2^160-45 = 2¹¹⁵

Which means that for every one of your 2⁴⁵ addresses you have generated there are 2¹¹⁵ addresses you have not.

Next, it has nothing to do with basic math, there is nothing basic about the math behind any cryptographic function.

Multiplication and division, adding and subtracting of exponents is very basic math.

Lastly, who needs 50% of the addresses? if a few thousand people had a few quadrillion addresses each it makes up a large enough percentage that a person is no longer chasing a moving target. It also means that every time you move your bitcoins, you have to wonder...... Has someone got the key for this address?

Not exactly sure what you meant by "a few thousand people" or a few quadrillion addresses so how about 4,096 people each with 16 binary quadrillion addresses?

2¹² x 2⁵⁴ = 2¹²⁺⁵⁴ = 2⁶⁶, 2¹⁶⁰/2⁶⁶ = 2^160-66 = 2⁹⁴

So for every one of the 2⁶⁶ addresses you have generated there are still 2⁹⁴ addresses you have not.

Ask yourself, how many bitcoin supporters are going to feel comfortable with their investment knowing that 15%, 10%, 5%, hell eve 1% of all bitcoin addresses are indexed and monitored. (the fed has already done this, that is where this project stemmed from)

You will never get even close to 1%, lets call it 2¹⁶⁰/2⁷ = 2^160-7 = 2¹⁵³ addresses, never.

No the fed has not done this.

Imagine everyone involved in crypto currency to date had the ability to randomly generate addresses using the same faulted PSRNG system that 80% of wallets use and fill even 100 gigs of space on a hard drive. How comfortable do you feel with your investment then?

Faulty random number generation is bad, very bad.  However it is faulty random number generation, not a flaw in Bitcoin itself.  If true (that many addresses were generated using a faulty random number generator) then thanks for pointing that out.  I use hardware random number generation so I feel pretty good about it.

Imagine as hard drives and storage become cheaper, As is we are already buying 6TB drives for $190usd. You can already go make a $70 investment and buy a 1TB external. With our software's it would take maybe a week for you to fill it and monitor it in real time. take that multiplied by even a thousand, and growing daily. How comfortable are you with your investment then?

Very comfortable, due to the math showing that is a very small amount of the total address space.

Imagine next year when Segate launches its first 10TB 5,200rpm HDD for only $350. (already in the works) Thats pocket change for most of us here....... You get the point. How comfortable are you with your investment then?

I am working on a 40TB drive, so what?  Still nothing compared to the entire 2¹⁶⁰ address space.

If you can honestly say that you still have no worries about your bitcoin after taking all that into consideration, then you sir are an idiot with no common sense.

No, I am an engineer using a hardware random number generator who understands and can do basic math.

Granted we are not giving you the WHOLE story yet, waiting on a few final developments that will make it all more platform neutral and basic user friendly so we are not just talking about it but letting everyone do it. But in summary, about a year ago, we were where you are now. In the very recent past, we have hijacked about 3.3BTC from a total of 5 addresses.

Can't wait for your WHOLE story.  Can't wait for you to prove you have moved 3.3 BTC with your method.

Developers who want to join the team and help spread awareness get the source now pending their contributions as well as a basic overview of how it works. The rest will have a beta platform within the next month or so to start cataloging their outputs, in a few months anyone who has some hard drive space that wants to catalog some bitcoin addresses has a chance to play along.

Sure, I am a developer with 30 years experience working on hard disk drive firmware.  Send me your information packet and I will take a look at it.

Final disclaimer,

Yes, if we find bitcoins we are taking them but this is not about being thieves. its about making people aware that 75% of the hype about bitcoin security is FALSE, even by the admission of some of the current bitcoin core developers. A direct quote from one of them in a recent interview "It is scary how many people have invested so much money in such a young technology that is filled with security flaws". We ourselves could not possibly steal enough bitcoin to make a difference, but as a community (full of thieves anyways) we could chip away at it and tally up enough hijacked coins over time to force the hand of the developers to assess the important and most prominent security flaws NOW before it drives bitcoin into the ground.

If you want to troll, go for it, we all love a good laugh and 80% of us on this forum are only here to see the dumb stuff anyways. Otherwise, just hang on and we will get you software soon so you can participate and put some of those old no longer used hard drives to good use.

BTW: Yes Hyena's laugh, ever wonder why? THEY ARE THE BIGGEST THIEVES IN THE ANIMAL KINGDOM

Question:  why not start a new thread now?  What is stopping you?

[Kluge]

There's no reason to start a new thread. This one has a fair number of subscribers all interested in DSV's goals. AFAIK, DSV is abandoned ATM. I doubt OP cares so long as chatter is relevant to the implicit mission statement.

I'd suggest the biggest indication of dysfunctional "address trolling" is that you need a lot of disk space. Why bother keeping addresses -- you'd just want to check them for coin or if they're likely to be active, yeah? If you have a backlog of 1.18PB, the software, I'd argue, is dysfunctional. The addresses should be checked as discovered to determine if they're active or hold coins, or both. In cases where coins are found, they should immediately be sent to the thief's address, but then they shouldn't be stored in memory since the legit owner knows it's compromised. In cases where the address is found to be active, it should be stored on file, but suggesting you need 1.18PB in storage for this is ridiculous. You've found 5 addresses with coins, right? Why store the other 1.18PB of them? Why are we even talking about storage space with an effort like this? You want to prove a government could monitor all these addresses, but this can be proven theoretically -- we know they could store a significant number of all addresses, but the trouble is in generating all of them and checking them, yeah?

If you're a thief, why release the software publicly? You sound like a white hat trying to pretend your a black hat (a "hyena"), so maybe just very humble -- one of those hardasses with a heart of gold. The alternative would be that you're full of shit and have dysfunctional software unable to achieve its goals. I doubt you, but don't mean to come off as hostile... I don't hold many coins but am definitely interested in objectively learning about progression in this field. All the best!

[BurtW]

As I understand it the idea is to have "a lot of people" continuously monitor "a lot of addresses" just in case one of them gets used in the future then, bam, take the poor saps money.

Now that I think this through a bit more, to do this they would have to store every private key they generate (so they can steal the money) plus every public key generated (to match to the incoming transactions in the blockchain) on the very off chance that one of them gets used in the future.  So, the storage requirement is not just the Bitcoin address or public key, it is at least all 256 bits of the private key + the public key(s) for pattern matching.

[Korbman]

I like this game!

Alright, so we all know imagining massive numbers is almost an impossible task. We can barely get our mind wrapped around numbers reaching the billions, let alone anything larger than that. With that in mind and feasibility aside, let's break this down financially instead.

Following BurtW's thinking:

I will use 32 bytes per address (2⁵ bytes per address) in my response.  Storage of addresses will actually take more than that so rounding to 2⁵ is in your favor.  I will also give you binary megabytes, terabytes and petabytes of storage which also works in your favor but makes the math easier.

And following Hyena's quote:

Imagine as hard drives and storage become cheaper, As is we are already buying 6TB drives for $190usd. You can already go make a $70 investment and buy a 1TB external. With our software's it would take maybe a week for you to fill it and monitor it in real time. take that multiplied by even a thousand, and growing daily. How comfortable are you with your investment then?

Imagine next year when Segate launches its first 10TB 5,200rpm HDD for only $350. (already in the works) Thats pocket change for most of us here....... You get the point. How comfortable are you with your investment then?

Let's say that, hypothetically, you had access to futuristic solid state SAS drives, granting you a full terabyte (1024 usable gigabytes) per 2.5" drive, only consuming 0.1W of power, and costing $100 each.
But let's take it a step further and say that you've got some supreme hardware/software compression capabilities that bring that 32 byte space requirement per address pair down to 16. At 16 bytes per address pair, each drive could hold a bit over 68,700,000,000 generated pairs (2⁴⁰ / 2⁴).

To hold the 1 quadrillion pairs you've mentioned, though, you'll need 14,552 drives.

Those drives would have an initial upfront cost of $1,455,200, but you'd need to use them somehow. What about a handy 4U 60-bay JBOD enclosure? That should work...though you'll need almost 243 of them, tacking on an additional $2,428,785 (before shipping, $9,995 each).

What about space? At 10 enclosures per 42U rack, those 243 4U units will take up at least 25 racks before additional equipment (servers, switches, firewalls, PDUs, etc). That's some expensive hosting.

Thankfully, the power consumption is negligible at this point. Ignoring the enclosure (which has a 1200W PSU), the drives alone will consume 1,456W. Don't worry though, the magical datacenter that stores all this equipment only charges $0.02 per kWh, so you'll only be paying $0.70 per day for all of them. Include the enclosures and you're probably sitting at somewhere between $30-$70 a day. Pocket change for what you've paid already.

So now you're at an initial cost of $3,883,985 just to be able to store the quadrillion addresses.

But let's say you've done it. You've put in the time, effort, and financing to secure the space needed to hold the addresses you've generate. As you look over the 25 racks of humming hardware, you begin to realize that you're now the owner of only 0.00000000000000000000000000000000000000000000000000000000000000000000000000011 579% of the total number of Bitcoin addresses that can ever possibly be generated ((2²⁵⁶ - 2⁵⁰) / 100). Congratulations on your achievement, and one can only hope you manage to win a lottery bigger than BTC3.3 for your efforts.

[BurtW]

The process of Bitcoin address generation is as follows:

1) Generate a cryptographically secure random 256 bit number, if it is too large go to step 1.

     This is the private key "p"

2) Calculate the public key, which is a point on the elliptic curve P = p*G

3) a = hash(hash(hash(P)))

4) add checksum, header byte, etc to the number a

5) Base 58 encode the result in step 4

The point is that statistical analysis of the public key value distribution tells you nothing about the statistical distribution of the random private key values.

Any statistical analysis of the Bitcoin address, especially the encoded Bitcoin address values, tells you even less about the statistical distribution of the random numbers used in the generation of the private keys.

The fitness of the cryptographically secure random number generator can not be tested or inferred from the resulting public key values or the Bitcoin addresses produced.

Food for thought.

[BurtW]

More food for thought:

If you analyse all private keys in base 58 encoded format you would find that all private keys start with 5H, 5J or 5K and none of the other possible two character starting sequences (51 ... 59, 5A ... 5G, 5L ... 5Z, 5a ... 5z) ever occur. 

Does that mean that all random number generators are broken?

No, this is simply an artifact of the base 58 encoding process.

[Hash Hyena]

Ok, we can keep it going here for now so long as the OP does not get upset over it.

The process in grabbing bitcoin from "collisions" successfully is a little more complicated than even you guys are pointing out now. But you are all on the right track. 95% of the equation is faults in the PSRNG's that almost all wallets or services use. So although that makes it a wallet problem. The wallet problem makes it a Bitcoin security problem as we all know that a computer can never truly generate random numbers.

We will explain how we have had success in a much greater depth in the weeks to come which will make it make a lot more sense. But still the magic is in having others, hopefully some of you with a few TB to spare do it yourselves. Once you do it successfully then the speculation and "i am a genius with big numbers" rhetoric can stop and we can all continue to bash away at the faults in the system forcing change and security. Sadly probably killing the price of BTC for a few months in the process.

It may sound malicious, and in the short term it is, but in the long run, its better to have it happen now while bitcoin is young so it can be fixed then years down the road when an issue like this could kill bitcoin forever. That is the reason we are going to open source the entire project. A few of us could do everything including steal YOUR bitcoin if that chance came up. But no matter what there would be tons of opposition saying that it was staged, faked, or whatever no matter how much you claimed you got ripped off. Let everyone have a chance at doing it themselves, Make a game out of it, track statistics through a web interface, etc. let the world have some fun with it, sooner or later people are going to realize that it is really happening, and change will be forced.

The reason it is taking time to get the platform released publicly is because we ourselves used a very complex Oracle DB which cost a small fortune. Not everyone can afford Oracle licenses, and to be honest, most already existing DB platforms either under perform for this purpose, or over complicate things so the basic user could not work it. So we are developing a way to replicate our platform WITHOUT using and existing DB technology so even the most basic of user can use and understand everything.

Please feel free to continue to speculate, post the fancy statistics and exponents on how impossible this all is as if the math is the only thing that matters. (that is not sarcasm, having all of that on the table when we get the time to show how it is done when we launch will make things easier to understand) and we will do our best to get this all launched as soon as we can.

I the mean time, any developers who want to jump on board to help speed up development for the user friendly platform, please message us, there are about a dozen of us [developers] working on this now, along with a few dozen mathematicians, statisticians, and even a half dozen cryptographers with over 45 years combined education. We are not hostile, in fact we are quite the friendly bunch. Although the process is malicious, the end result could save our precious bitcoin from total failure. It can happen, ask any one of the core developers, there are a lot of faults in BTC that could cause it to die if exploited, they wont list them for you, but the will confirm they exist and it is very possible. We just happened to find one.

Thanks for reading 

[HELP.org]

Wouldn't one of those hardware random number generators solve this?  Could something like http://www.entropykey.co.uk/ be incorporated into a wallet system.

[Dabs]

One day, maybe in a few months or a few years, we might slowly migrate over to 512 bits. Suddenly, you're just wasting disk space.

And don't forget about compressed keys.

[BurtW]

It is true that faulty random number generation can lead, and in the past has led, to bad things happening including loss of BTC.

If it is true that there is a widely distributed faulty random number generator being used to generate private keys and digital signatures then that needs to be found and fixed as soon as possible.

This all leads to a very interesting side issue:  how can you ever prove you have taken someone else's BTC using this or any other method?  Ideally you would have someone very reputable come forward and say "someone took my BTC in this transaction" and post the transaction.  This could be followed by the party that took them coming forward and signing a message with the private key of the destination address of the transaction in question.

The reputation of the person that lost the BTC in the transaction would have to be beyond reproach as there are many ways to fake this whole "Proof of Theft" scenario.

I believe that your idea of having someone of high reputation run your program, with it they create a verifiable address collision, and then they report the address collision would also work as proof that you are on to something.

[BurtW]

You might be interested in the 50 BTC reward offered in the following post.  The offer has expired but you might be able to talk Greg into extending the deadline just for you.

So you claim you can crack some random keys provided by people on the forum? Oh really.

Well here, I'll make it very profitable for you then:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


I, Greg Maxwell, do hereby promise to pay 50 BTC to the first person that
provides the discrete log of _any_ of the following randomly generated
200,000 secp256k1 public keys. This offer is open until 2014-04-01.

None of the below public keys have been used on the Bitcoin blockchain as
of the time of the creation of this offer.

04abb9239d3a5131de45b977807c62bf879119b05c3da33e37d8e7be0901985ce73b6ca6dff5b97 34d1225ce0120bbe023066669c29e23d3ea82de9a57dd259b63

Full message at https://people.xiph.org/~greg/keysfun.asc

Surely if you can crack a single key provided by a person in the thread cracking any one of 200k keys should be a cinch.

[HELP.org]

You might be interested in the 50 BTC reward offered in this post:

That is not the same thing.  That is reversing a specific key.  This is about the birthday problem where there is a collision and you can't choose the specific address in advance or the statistics are vastly different. 

[BurtW]

You might be interested in the 50 BTC reward offered in this post:

That is not the same thing.  That is reversing a specific key.  This is about the birthday problem where there is a collision and you can't choose the specific address in advance or the statistics are vastly different.  

Very true.  That is why I said "might be" interested.  I expect the 200,000 addresses Greg generated were generated with a very good random number source so those 200,000 addresses would not fall into the net (possible bad private key generation) being cast by the Hyenas.

[Hash Hyena]

Wouldn't one of those hardware random number generators solve this?  Could something like http://www.entropykey.co.uk/ be incorporated into a wallet system.

Yes, to a point. The biggest part of the fault is that the PSRNG's after a period of generation across a large scale tend to cluster outputs, meaning a large part of addresses fall in a small part of the key space. As a temporary solution for added security if you yourself are trying to store any amount of bitcoin long term, we can recommend one of a few methods for now.

1: use vanitygen to generate an address which falls far out of reach of the clustered address space, for example, the odds of your address eventually becoming part of someones catalog if it starts with 11121******************* is 667% more likely to happen then if your address starts with 1iBPq******************* for example.

If you extract a total list of all bitcoin addresses ever used. Then turn them into a line graph based on the first 6 characters of the address then sort them alphabetically and numerically you will see better what we are talking about. A scary large amount of addresses fall within a very small percentage of the total available address space. That in and of itself is roughly 60% of why we have been able to be successful with our project.

2: Use real world high entropy sources, a deck of cards, Hexadecimal dice, numbers and letters pulled from a hat. Myself personally and a few of the guys already on the team for this project we throw darts at a very large dart board that we made that has 0-9, a-f listed about 400 times each in a random pattern on a 4' X 4'  custom dart board we made. The entropy is higher if you are drunk when throwing the darts as your hand eye coordination makes it like trying to hit a moving target  

3: store your bitcoin in multiple addresses to ensure that the prize isn't sitting in one location, myself i have about 40 addresses with positive balances at any given time. Not a single one has more than BTC5 in it, and not a single one has ever been online. I use paperwallets created from a 5 year old laptop with no hard drive or NIC card in it. I use the darts to generate keys, then use an ubuntu live cd to make the paper wallets on my own custom template which folds and then fits inside of a 4 screw acrylic baseball card holder. I then keep the acrylic cases spread between a few separate safety deposit boxes at a few banks. Most of them are left in my will to my wife and daughter.

There are several safer ways to store bitcoin and keep it safe. The security problem is not in finding safe ways to store bitcoin, the problem is in using bitcoin for commerce as those wallet clients and even the bitcoin core itself continue to dump addresses into the clustered regions of the address space. When it becomes a serious problem, retailers will lose faith in it as a payment method and adoption of acceptance will begin to fall.

 

One day, maybe in a few months or a few years, we might slowly migrate over to 512 bits. Suddenly, you're just wasting disk space.

And don't forget about compressed keys.

Any disk space spent in the processes of trying to force the hand of the bitcoin core devs to fix a problem is not wasted. Your very narrow minded comment shows you have very little understanding of core address concepts and where security faults lay. 512 bits would just require re-building new data tables and populating them with new data based on the faults in PSRNG's. yes it would now require double the disk space to store them until better compression methods are developed, but it still does not fix the problem.

Your feeble attempt at trolling with such replies only discredits your comments and speaks poorly on your intelligence or ability to understand where the problem lays

You might be interested in the 50 BTC reward offered in the following post.  The offer has expired but you might be able to talk Greg into extending the deadline just for you.

So you claim you can crack some random keys provided by people on the forum? Oh really.

Well here, I'll make it very profitable for you then:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


I, Greg Maxwell, do hereby promise to pay 50 BTC to the first person that
provides the discrete log of _any_ of the following randomly generated
200,000 secp256k1 public keys. This offer is open until 2014-04-01.

None of the below public keys have been used on the Bitcoin blockchain as
of the time of the creation of this offer.

04abb9239d3a5131de45b977807c62bf879119b05c3da33e37d8e7be0901985ce73b6ca6dff5b97 34d1225ce0120bbe023066669c29e23d3ea82de9a57dd259b63

Full message at https://people.xiph.org/~greg/keysfun.asc

Surely if you can crack a single key provided by a person in the thread cracking any one of 200k keys should be a cinch.

This in itself is not an achievable target. If he used true entropy not from software or a computer, these 200k addresses fall across the entire keyspace, the problem is that to date mainly due to commerce and the bitcoin core, a VERY LARGE amount of addresses fall in a very small portion of the space.

The project is not aimed at trying to target a specific address, or even 200k specific addresses, the project is aimed at cataloging those small portions of address space which are heavily over populated with positive balances based on the core PSRNG's faults thus seriously increasing the odds of gettins someones bitcoins. The address is not what is important, the address space is. If that makes any sense.

[Hash Hyena]

It is true that faulty random number generation can lead, and in the past has led, to bad things happening including loss of BTC.

If it is true that there is a widely distributed faulty random number generator being used to generate private keys and digital signatures then that needs to be found and fixed as soon as possible.

This all leads to a very interesting side issue:  how can you ever prove you have taken someone else's BTC using this or any other method?  Ideally you would have someone very reputable come forward and say "someone took my BTC in this transaction" and post the transaction.  This could be followed by the party that took them coming forward and signing a message with the private key of the destination address of the transaction in question.

The reputation of the person that lost the BTC in the transaction would have to be beyond reproach as there are many ways to fake this whole "Proof of Theft" scenario.

I believe that your idea of having someone of high reputation run your program, with it they create a verifiable address collision, and then they report the address collision would also work as proof that you are on to something.

We greatly feel the same way. hence the reason we are taking to time to re-develop the entire platform to make it basic user friendly on our own dime and then giving it away to the world. We could talk about doing it all day long, but as you said, the proof is in the pudding. Some of the higher reputation members would need to build large catalogs themselves and then find a collision. We are not doing this to troll, not for the thrills of stealing bitcoin, surely not to make a profit as the hard drives and hardware we have had to buy ourselves exceeded a cost that we could ever hope to recover through BTC theft. This is simply to allow easy access to the right people that need to do this in order to "prove" it. We have done it, we can prove it, but not to a level which will satisfy the community, so we are going to allow everyone to take a shot at it in hopes that the right person gets it done.

[Dabs]

One day, maybe in a few months or a few years, we might slowly migrate over to 512 bits. Suddenly, you're just wasting disk space.

And don't forget about compressed keys.

Any disk space spent in the processes of trying to force the hand of the bitcoin core devs to fix a problem is not wasted. Your very narrow minded comment shows you have very little understanding of core address concepts and where security faults lay. 512 bits would just require re-building new data tables and populating them with new data based on the faults in PSRNG's. yes it would now require double the disk space to store them until better compression methods are developed, but it still does not fix the problem.

Your feeble attempt at trolling with such replies only discredits your comments and speaks poorly on your intelligence or ability to understand where the problem lays

Hey, I wasn't trolling. I thought you were. I was just answering. I did not realize it at first but you are talking about a possible fault in the PSRNG. I personally use vanitygen because it seemed like a good idea for cold wallets.

The only time I let bitcoin core generate addresses for me was when I was sending bets to satoshidice.... a long time ago.

This in itself is not an achievable target. If he used true entropy not from software or a computer, these 200k addresses fall across the entire keyspace, the problem is that to date mainly due to commerce and the bitcoin core, a VERY LARGE amount of addresses fall in a very small portion of the space.

The project is not aimed at trying to target a specific address, or even 200k specific addresses, the project is aimed at cataloging those small portions of address space which are heavily over populated with positive balances based on the core PSRNG's faults thus seriously increasing the odds of gettins someones bitcoins. The address is not what is important, the address space is. If that makes any sense.

Since I use vanitygen, then I guess my coins are safe. There's another program out there called paperwallet or paperwal that, to me, seems to use the entire address space. Those generated addresses would probably be secure.

And of course, when I am really bored, I roll 100 dice. (or take random pictures and generate a key out of that.)

Basically, use any other RNG but not the one in bitcoin core. The android client had a big problem some time ago, related to the RNG.

[Hash Hyena]

One day, maybe in a few months or a few years, we might slowly migrate over to 512 bits. Suddenly, you're just wasting disk space.

And don't forget about compressed keys.

Any disk space spent in the processes of trying to force the hand of the bitcoin core devs to fix a problem is not wasted. Your very narrow minded comment shows you have very little understanding of core address concepts and where security faults lay. 512 bits would just require re-building new data tables and populating them with new data based on the faults in PSRNG's. yes it would now require double the disk space to store them until better compression methods are developed, but it still does not fix the problem.

Your feeble attempt at trolling with such replies only discredits your comments and speaks poorly on your intelligence or ability to understand where the problem lays

Hey, I wasn't trolling. I thought you were. I was just answering. I did not realize it at first but you are talking about a possible fault in the PSRNG. I personally use vanitygen because it seemed like a good idea for cold wallets.

The only time I let bitcoin core generate addresses for me was when I was sending bets to satoshidice.... a long time ago.

This in itself is not an achievable target. If he used true entropy not from software or a computer, these 200k addresses fall across the entire keyspace, the problem is that to date mainly due to commerce and the bitcoin core, a VERY LARGE amount of addresses fall in a very small portion of the space.

The project is not aimed at trying to target a specific address, or even 200k specific addresses, the project is aimed at cataloging those small portions of address space which are heavily over populated with positive balances based on the core PSRNG's faults thus seriously increasing the odds of gettins someones bitcoins. The address is not what is important, the address space is. If that makes any sense.

Since I use vanitygen, then I guess my coins are safe. There's another program out there called paperwallet or paperwal that, to me, seems to use the entire address space. Those generated addresses would probably be secure.

And of course, when I am really bored, I roll 100 dice. (or take random pictures and generate a key out of that.)

Basically, use any other RNG but not the one in bitcoin core. The android client had a big problem some time ago, related to the RNG.

Our apologies for accusing you of trolling,

"any other" RNG does not really solve the problem as we have found through heavy testing that Armory, Electrum, MultiBit, and just about every other wallet client out there has the same problems. The problem really is ANY RNG that is based on software.

Paperwallet is a better source as it uses coordinates of a mouse on the screen so it has i direct input which affects the output. Something like that built into a wallet client would not be feasible as no person is going to sit behind a PC at bitpay and wiggle a mouse every time someone needs a payment address generated.

The bottom line is, computers cannot generate randomness on their own, for it to be truly random it needs human input. The solution will be in the scope of something that requires a 3rd authentication process to spend bitcoins from an address. We ourselves have had many discussions on what a solution would be, but we do not have the answer yet. only ideas. 

[HELP.org]

here is the Armory discussion:
https://bitcointalk.org/index.php?topic=673035.0;all

[Dabs]

Don't modern RNGs regularly get input from mouse, keyboard, hard drive, and other sources? And some of the newer Intel chips have hardware RNGs.

And if you're using bitcoin core on a computer, surely it can be improved by constantly getting randomness from mouse or keyboard input.

I saw this in the armory thread:
http://ubld.it/products/truerng-hardware-random-number-generator/

This is actually something I might consider for my new gaming site. (Provably Fair, of course.)