The first mechanism apply also to address generation. Other mechanisms, such as side channel can applied to address generation too. So saying that public key exposure is not safe and discourage it is not justified at all. People who think that SHA is more safe than ECC has no argument to justify this. No one can say which algorithm will be defeated first. Again there is no proof that SHA cannot be reversed. Having the feeling that SHA is more safe than ECC because ECC is based on large integer arithmetic is just a feeling. Not a fact ! "A more optimized search algorithm" can also apply to SHA. |
|
|
|
|
Up to now, exposing public key is safe. They're might be wrong implementation of signature software that can allow to guess the private key, that's true. But it is the exactly same problem for addresses generation. Side channel attacks are also possible on software that generates addresses. Lot's of people reuse addresses and continue to do it. Without speaking of privacy, exposing public key is as safe as exposing address. Be afraid of a conspiracy or of unknown mechanisms that can allow your private key to be discovered is totally unjustified.
|
|
|
|
|
A true 256 qbit register does not exists and probably won't exist. All "quantum computer" today are based on "retry" which means that to experiment a true state superposition over a large number of qbit you need in fact many tries and this number of tries increase with the number of qbit. No worry from the QC.
ECDLP and SHA are not yet vulnerable and no argument can indicate that ECDLP is less vulnerable than SHA. ECDLP256 has a security of 128bit since the beginning and no significant improvement has been made despite intensive research.
|
|
|
|
Neither RIPEMD-160 nor SHA256 are subject to such attack. They are not analytical and only a brute force attack is feasible to be run by adversaries which is not practical and will not be practical in foreseeable future, hence, they are safe now.
Yes SHA256 and RIPEMD160 algorithms are safe today but even if they are not linked to large number arithmetic, there is not proof that they cannot be reversed or predicted in polynomial time and space. As for ECDSA, they is no proof that ECDLP cannot be solved. Today the security of ECDLP256 is ~128bit and 160bit for RIPEMD160. Both are not feasible today but the probability that someone find a way to solve ECDLP256 or to reverse hashing algorithms is not zero. It is not possible to predict which algorithm will be defeated first. There is no objective reason to say that exposing ECDSA public key for a long time is less safe than exposing an address. |
|
|
|
Thanks for the link, I will have a look at this. Adding a way to generate only upper or lower case is easy except for the difficulty calculation. Jean_Luc
Here's your piece of code for generating pseudorandom numbers.
...
Thanks for the info but as written in the readme it is better to use a seed for generating a safe base key and obviously to run it on a machine where you are alone. The PNRG is not used at all by default, it is enabled only if you want to use the -r option which I do not recommend (I will add a UNSAFE message in the command line usage infos for the - r option). |
|
|
|
Hi there  Some news: - The case insensitive search is ready and working well at almost nominal speed. - For the search with wildcard, the speed is still very low, in that case I have to calculate the full base58 address for each generated point and the base58 is very slow, so I'm trying to implement this at the GPU level. - I will also add an encryption mechanism for the output file and think to a manner to have a safe command line. |
|
|
|
QC is not the problem (not now) but your estimate about "billions of years" is not correct. There are good reasons to avoid re-using bitcoin addresses:
Breaking ESDA is about prime factorization and not brute forcing sha2, hence it has nothing to do with ASICs used in bitcoin network. It is an active research field in mathematics and although it is hard to believe in discovery of a magical algorithm improvements are absolutely possible. Meanwhile Moore law is still working and attack costs are decreasing constantly.
This was just a comparison, if you consider having an equivalent power to the whole BTC network with ASIC dedicated to ECC (not SHA2) , breaking a single key would require several billions of years using the faster algorithm known today. I agree with you, the most probable thing is that someone find the way to solve ECDLP in polynomial time and space, in that case, bitcoin would die immediately. More importantly, it is not just about the algorithm itself, side channel/implementation dependent attacks are another serious class of threats.
In that case, your address is also not safe. And we have conspiracy theories about NSA and its history of implanting back doors in its products.
Don't worry about that ! You can check the order of the curve, its embedding degree, primitive roots of unity, etc,... all is ok ! Finally, there is no reason to encourage disclosure of public keys and becoming exposed to various range of potential attacks specially when it comes to sensitive utxos which are supposed to stay live for long times and hold significant amounts of bitcoin.
There is also no reason today to discourage exposure of public key. |
|
|
|
|
No risk to expose the pubkey. No powerful enough quantum computer exists today. Creating a true 256 qbit register is technically as hard as solving ECDLP256 with a classic supercomputer. If you consider a specific supercomputer (based on ASIC dedicated to ECC) with an equivalent power of the whole BTC network, solving a single key would require several billion years.
|
|
|
|
can you add an option to search all address in lowercase or upper case?
I'm not sure to fully understand your request ? Could you be more precise ? Hello, @Jean_Luc!
First of all I want to say a big thank you for the amazing project you are developing. Just a huge pleasure to use it.
Had you been thinking about expanding pattern abilities? Search for a word at the end of an address or inside an address? What do you think about the implementation of regular expressions?
I know regex in vanitygen working with CPU only. I don't know if this is possible but I think it would be just awesome to see something like a hybrid algo for finding regex patterns faster.
Thank you!
What do you think about using wildcard and using pattern like 1*Bit*Coin* ? |
|
|
|
|
No, this is not difficult to implement.
I'll add this feature in the new release.
|
|
|
|
No, for the moment, nobody has proposed an OpenCL kernel for VanitySearch and I didn't find a good bigint library for OpenCL. If somebody has some infos, it would be appreciated |
|
|
|
I tried using Vanitygen and I tried creating an address that starts with 1spadormie and 50% in 5000+y lol. So I stop trying to create address such. A 4 letter word is so much faster than that.
Can Vanitysearch solve my problem?
A 9 letters case sensitive prefix starting with a 's' is hard. (Difficulty ~ 173346595075428800) Here the result of VanitySearch for such a prefix with a GeForce GTX 645: GPU: GPU #0 GeForce GTX 645 (3x192 cores) Grid(24x128) 46.178 MK/s (GPU 43.597 MK/s) (2^28.50) [P 0.00%][50.00% in 82.5081y][0] To solve such a prefix in one month (in average) using VanitySearch, you need a power of ~50GKs (50 GTX 1080 Ti  ) Edit: If you agree to have 15padormie instead of 1spadormie, with a GTX 1080 Ti, you can solve it in one month. |
|
|
|
why the result is not saved in txt?
You can use the -o option to save within a file. |
|
|
|
Thanks for the test You didn't reconstruct the final private key with the good key, you have to use the first generated private key (for -rp) which is the one which should be kept secret by the requester of the prefix. C:\C++\VanitySearch\x64\Release>VanitySearch.exe -rp KxFuiDGdGLoMKGnVfZ4x4sXLs6GPkp2a7teATCyLV65XKxt65s35 keyinfo.txt
Pub Addr: 1Laure3pgFU6v1EdqT15B9SQ612tTBS4WE
Priv (WIF): p2pkh:L1PqadvjgQJ7XXQZ8c8hf7j8RRu7F7J8Fws1t3Zasd7qiXjwyLwT
Priv (HEX): 0x7C8F3FC0B693F368219BD4F7DCE82C10FEBFA2F9CBB1FD55EF5B68DE24411C6C
|
|
|
|
Hello, my Bitcoin Wiki user name is jlpons. I'll appreciate to be able to edit articles. Many thanks  |
|
|
|
In fact i already added the feature. It is committed on GutHub but not yet released (there is still a bug, from time to time the address cannot be reconstructed) Few word for those who want to test from the source: Case: Alice want a nice prefix but does not have CPU power available, Bob has the power but cannot know the private key of Alice. Alice generate a key pair then she sends the public key and the wanted prefix to Bob: C:\C++\VanitySearch\x64\Release>VanitySearch.exe -s "AliceSeed" -kp
Priv : L4U2Ca2wyo721n7j9nXM9oUWLzCj19nKtLeJuTXZP3AohW9wVgrH
Pub : 03FC71AE1E88F143E8B05326FC9A83F4DAB93EA88FFEACD37465ED843FCC75AA81
Bob runs VanitySeacrh using the Alice's public key and send back the keyinfo.txt file to Alice: C:\C++\VanitySearch\x64\Release>VanitySearchCUDA8.exe -sp 03FC71AE1E88F143E8B05326FC9A83F4DAB93EA88FFEACD37465ED843FCC75AA81 -gpu -o keyinfo.txt -stop 1ALice
VanitySearch v1.12
Difficulty: 264104224
Search: 1ALice [Compressed With Public Key]
Start Wed Apr 17 20:03:19 2019
Base Key: 8B456380CE20C7CA2ACA52A6B17EB53B98C789AD8215F09D1D478260492E7DD3
Number of CPU thread: 3
GPU: GPU #0 GeForce GTX 645 (3x192 cores) Grid(24x128)
49.429 MK/s (GPU 45.930 MK/s) (2^26.60) [P 31.92%][50.00% in 00:00:01][0]
File keyinfo.txt: Pub Addr: 1ALiceQeUJwFKwGYLvZDMfKC1h9XCshLJ7
PartialPriv: L54zKpetuL8rVVvyWRFJG8PdQs4PaPuvP3Rb7G8SXLBVSjLsMx4m
Alice runs VanitySearch using her first generated private key and the Bob's file to get safely the final private key: C:\C++\VanitySearch\x64\Release>VanitySearchCUDA8.exe -rp L4U2Ca2wyo721n7j9nXM9oUWLzCj19nKtLeJuTXZP3AohW9wVgrH keyinfo.txt
Pub Addr: 1ALiceQeUJwFKwGYLvZDMfKC1h9XCshLJ7
Priv (WIF): p2pkh:L1kjZP36qVCcp1eXXJE7CfyuWojc1rCTw8Xs8rNrCxM5imLgm4ro
Priv (HEX): 0xD874F31B0B73ED255865FEB210C181589A860ACDB4C374FB4F685DFE2077797F2
|
|
|
|
Yes this can be done. I'll add this feature ASAP. |
|
|
|
1BTC is calculated on average according to the mode 10 to 15 times slower faster than 1Tes
Yes this is due to the pivot at 1QLbz7... (The switch from 0x[00]FFFFFFFF.... to 0x[00]0XXXXXXX...). Thanks for the tests. |
|
|
|
|
Hello,
I fixed the issue. New release 1.12 is ready. I upload the CUDA8 ASAP.
The bug was due to 'negative zero' when a match was found for a symmetric point at index 0 of the group.
In that case the symmetric point noted -0 was interpreted as 0.
It did not affect compressed address because, for that case, the y value of the point does not matter (the parity is handled using an other way).
So I simply applied the same logic for compressed and uncompressed, it should work fine.
It happened with a probability of 1/(GPR_SIZE*2) = 1/2048.
Many thanks to Lolo54 for all the tests.
|
|
|
|
|
Show Posts
