Search content
Sort by
Showing 5 of 5 results by Gerbie
Quote
I found that random searches sometimes gave me the same results several times. That means I'm scanning the same keys more than once!
What size search range were you using? It must have been a somewhat small one relative to GPU speed.I don't know the exact range, but yes it was relatively small, so I knew I could scan the full range with 30 Minutes on a Google Colab T4. That made me wonder, is that specific for a small range, or will it happen with a large range as well, only that I don't notice it (so easily)...?
I tend to test in small steps, so I can see what happens. The numbers are so huge, that my small brain has to split it in smaller bits... and I don't want to run a test for several weeks to find out my idea is not working at all and I just wasted resources.
Another point of discussion for which someone here might have expertise: random search.
I found that random searches sometimes gave me the same results several times. That means I'm scanning the same keys more than once!
Here again we have maths (statistics).
Imagine a big bag full of green beans and only one red bean (the private key we're looking for). If I pick a random bean blindly from the bag and throw it back if it is not the red one, every bean I pick will have the same incredibly low probability of being the red one. And for each pick, the chance of getting the red one will be the same as taking the one I threw back before... So I might end up scanning a lot more keys than the size of the range before I find the private key.
So even if I count the number of beans I test, I have no guarantee that after testing as many beans as there are in the bag, there will be no red bean. Maybe I was just unlucky and didn't pick it.
Any constructive thoughts/opinions on this?
I found that random searches sometimes gave me the same results several times. That means I'm scanning the same keys more than once!
Here again we have maths (statistics).
Imagine a big bag full of green beans and only one red bean (the private key we're looking for). If I pick a random bean blindly from the bag and throw it back if it is not the red one, every bean I pick will have the same incredibly low probability of being the red one. And for each pick, the chance of getting the red one will be the same as taking the one I threw back before... So I might end up scanning a lot more keys than the size of the range before I find the private key.
So even if I count the number of beans I test, I have no guarantee that after testing as many beans as there are in the bag, there will be no red bean. Maybe I was just unlucky and didn't pick it.
Any constructive thoughts/opinions on this?
A very interesting discussion!
Perhaps someone with the hardware to test it can help.
The prefix "1BY8GQbnueY" or even "1BY8GQbnue" is too long though. We should start with a shorter one to test the principle and look for the distribution.
Depending on your hardware, "1BY8GQbn" or "1BY8GQbnu" might work.
Search for these prefixes. If you find several of them, take two very close together and scan in the area between them. If you find another one, narrow the range again to the smallest range in between. This way we can find an expected distance value for that prefix.
Then test this on other prefixes you found, and you can see if the value you found is also close to the distances between the other prefixes. However, there will be a deviation, so allow some margin when setting the ranges. It might lead to some kind of average, but of course there is no guarantee. Some prefixes will be an "exception" and be much closer or further away.
On the other hand, what is missing from the discussion are the ECC calculations. Two consecutive private keys can generate two public keys very close to each other, or very far apart. These values are then hashed and so on to generate the address... I would say that the chance of two successive inputs generating hashes and addresses close to each other is very unlikely, but thanks to ECC we have no clue about the input of the hash (based on the private key)...
For my part, I would appreciate a more factual and respectful discussion, let's get emotional (and maybe even drunk) when you find a private key
Perhaps someone with the hardware to test it can help.
The prefix "1BY8GQbnueY" or even "1BY8GQbnue" is too long though. We should start with a shorter one to test the principle and look for the distribution.
Depending on your hardware, "1BY8GQbn" or "1BY8GQbnu" might work.
Search for these prefixes. If you find several of them, take two very close together and scan in the area between them. If you find another one, narrow the range again to the smallest range in between. This way we can find an expected distance value for that prefix.
Then test this on other prefixes you found, and you can see if the value you found is also close to the distances between the other prefixes. However, there will be a deviation, so allow some margin when setting the ranges. It might lead to some kind of average, but of course there is no guarantee. Some prefixes will be an "exception" and be much closer or further away.
On the other hand, what is missing from the discussion are the ECC calculations. Two consecutive private keys can generate two public keys very close to each other, or very far apart. These values are then hashed and so on to generate the address... I would say that the chance of two successive inputs generating hashes and addresses close to each other is very unlikely, but thanks to ECC we have no clue about the input of the hash (based on the private key)...
For my part, I would appreciate a more factual and respectful discussion, let's get emotional (and maybe even drunk) when you find a private key
Re: == Bitcoin challenge transaction: ~1000 BTC total bounty to solvers! ==UPDATED==
Guys if we found public key for puzzle 67,68,,69
will it make it easier to find private keys ?
i know the public key but dont know what to do
will it make it easier to find private keys ?
i know the public key but dont know what to do
Dear Astax51,
in the lower bit-range, like puzzle #67, 68 and 69, having the public key is like having the private key.
With the public key it takes a maximum of a few minutes to get the private key.
This is also what happened when the puzzle #66 was solved and tried to transfer the bitcoins. After broadcasting the public key for the transaction, it was picked up by bots which used it to calculate the private key and made a RBF transaction with a higher fee to replace the original transaction and so stole the bitcoins.
If you have the public keys, and know how to handle them, you'll have the private keys. But:
1. as soon as you give someone the public key, consider the bitcoins lost.
2. if you manage yourself to find the private key, transferring the bitcoins is very risky. There is a big chance, they get stolen by bots.
So be very careful who you trust and work with...
Kind regards, best wishes and good luck!
Dear @Baskentliia,
It may be because English is probably not your first language, but saying to Jean Luc "We expect you" is pretty rude.
The "prize" for solving puzzle #130 is very high, so don't expect to be able to do it with someone else's tools/software.
If you want to solve one of the remaining puzzles, you have to team up with a lot of people (and share the prize money) or be smarter than everyone else, i.e. come up with a new method or code to do it much faster than is possible with the actual hardware and software.
In fact, showing how secure the bitcoin crypto is was the whole idea behind these puzzles.
And a 256 bit range is ridiculous at the moment, please do the maths and calculate how many resources you'll need to solve a 256 bit number! That's why the puzzles stop at 160 bit...
Sincerely and good luck puzzling!
It may be because English is probably not your first language, but saying to Jean Luc "We expect you" is pretty rude.
The "prize" for solving puzzle #130 is very high, so don't expect to be able to do it with someone else's tools/software.
If you want to solve one of the remaining puzzles, you have to team up with a lot of people (and share the prize money) or be smarter than everyone else, i.e. come up with a new method or code to do it much faster than is possible with the actual hardware and software.
In fact, showing how secure the bitcoin crypto is was the whole idea behind these puzzles.
And a 256 bit range is ridiculous at the moment, please do the maths and calculate how many resources you'll need to solve a 256 bit number! That's why the puzzles stop at 160 bit...
Sincerely and good luck puzzling!