Topic: 2^256 Deep Space Vagabond - page 2. (Read 38752 times)

This is an interesting project, but I have some questions as a spectator of it. Do they do it as a hobby in their free time? If not then who is paying the team? Are they on a payroll? What is your budget that you are dedicating to this whole operations? Because you can't do it with 3.3 BTC.

Multisig addressses solves the risks associated with an address controlled by a single private key.

Alright, I'll bite thanks to my incessant curiosity. PM sent, and I'll put together a review if permitted.

Hi Burt,

a lot of progress, and a small amount of BTC claimed already, but nothing we would brand as "news" yet. Poke around the web a bit over the past week and a half and you will start to see a pattern or trend of people asking "did anybody else have their bitcoin stolen"? or things of that nature,  but we have not hit a target big enough, or enough small targets to brand it or make it news worthy as any publication of anything at the moment will result in nothing but a bunch of trolling from the mindless masses of sheeple in the crypto currency space. As time progresses more and more clear patterns emerge where the real source of the missing bitcoins come into question things will become more clear. For now, if you are one of those unlucky few who have become victims. Please maintain the address your BTC was hijacked from as we will be returning it to its rightful owners once enough have been collected to make an impact, all you will need to do is show you can send a transaction from the hijacked address showing you were the original holder of the private keys for that address.

In the interim, anybody wanting copies of some of the tools we are using, and help getting set up so you too can participate, please contact us and we can get you some of the pre-release versions with limited functionality (still enough to start grinding away at claiming BTC). we are aware that there will be people with malicious intents using this software and we can do nothing about that, but we ask that you refrain from doing so and that any BTC you can claim and move is returned to its rightful owners upon proving they were in possession of the keys for that address in the first place

Things you will need beyond our tools.

Either a dedicated Linux machine, or a VM with at least 2gigs of ram.
JRE and JDK
a host machine with fair amount of hard drive space and recommended 4 gigs of ram.

We will gladly walk you through getting everything set up until requests exceed our time limits, please keep in mind we are still working hard at finishing all the tools so everyone can participate so we are limiting our time in "setup assistance"

Any news from Hash Hyena?

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.)

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

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. 

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.



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.

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.

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.

 
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


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.

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.

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. 

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.

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.

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.

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.

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 

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.

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.