What kind of storage does a particle accelerator use? That's interesting. Those things are like giant lasers or something and you break atoms and stuff right?
I'm guessing this is one of those circular particle accelerators, where the beam goes round and round for some time.
Yes it is a circular ring, diameter ~270m,energy 6GeV. (ESRF at Grenoble/France). We don't break atoms, we accelerate electron to produce hard Xray. Those xray are used in beamlines all around the ring to explorate matter. A bit like a giant microscope. |
|
|
|
Since Jean_Luc has been offline and not updated in a while I think the only new speed increases will be with new cards not from software updates.
-Dave
Hi there, I'm still very busy at the moment but I will definitely restart to work on the project soon. I'm working in a particle accelerator and we have rebuilt the storage ring. We have just started the commissioning phase yesterday. When we will get a stable stored beam at nominal settings, I will have more time to work again on personal projects. |
|
|
|
Yes, I figured it out, it’s impossible to fix it by saving 6 algo, so..
Yes, by using AddDirect you can effectively reduce the problem to case 1 but you loose all benefits, it is like generating random number, add it to the starting key and check the address. IMHO, the best way is as you have done, keep only case 1 and can keep the group optimization. (by the way, why does release sm30 load sm60 cores, is there no error here?)
Release SM30 is especially here for debugging purpose. COMPARE if runtime right: 196s / 125s = ~1,56 if hashrate right: 195MK/s / 105Mk/s = ~1,85 VanitySearch win!  (issue created "need symmetry when calculating batch inversion" github.com/brichard19/BitCrack/issues/188, await..) Thanks for the comparison  |
|
|
|
|
Hello,
I really don't have much free time at the moment to work on this program.
But by using AddDirect you loose all benefits of goup/sym/endo because AddDirect requires a modular inversion which costs hundreds of modular multiplications. goup/sym/endo optimization is done to avoid slow modular inversions.
|
|
|
|
Hello. First of all: great work! TL;DR: Can this software guess what characters are missing in pair: 1DLLsqnKALAk9XDx2ugYNBHn6jfLLDiE1
L2vhmg**********3a3pkSrW986Cx2cUyAnj7x2pXvASqvHBkQb8
Hello, As it is no, it is not optimized for that. However with few modifications of the code and a powerful hardware it can be done... |
|
|
|
|
Here is the way the final private key is reconstructed:
1) (privKey + partialKey) mod n
2) (lambda1 * privKey + partialKey) mod n
3) (lambda2 * privKey + partialKey) mod n
4) (-privKey + partialKey) mod n
5) (-lambda1 * privKey + partialKey) mod n
6) (-lambda2 * privKey + partialKey) mod n
As you don't know the privKey when mining , it is not possible to calculate an offset to add in order to reduce to case 1.
May be I also missed something...
|
|
|
|
|
Hello,
Yes the split key is done using all the 6 ecc algorithms, reduce it to only one is not obvious.
I don't know exactly how Vanitypool is working, does it support only "add" algorithm for final private key reconstruction ?
Vanitypool supports only uncompressed addresses or both ?
|
|
|
|
|
OK, i wrote this a bit too fast. I was thinking to create a random walk for the birthday paradox on the hash of the signature in order to exploit it the signature process but it ends in solving the discrete log using classic random walks (of course, with public key previously exposed). So it is even not necessary to create a random walk from the signature hash.
|
|
|
|
Signing messages is fine to prove ownership.
Of course you wouldn't sign a message like "i own this address".
You would include your name, the current date and the reason for signing this message. And eventually even a random token from the person who wants you to prove the ownership.
Right, this is the good way to do however it is better to define the full format of the message to sign (including restrictions on the fields) with the third party in order to prevent from a birthday paradox attack on the signature. |
|
|
|
Done |
|
|
|
Hello, Many thanks Dave for you work A friend of me use a GTX 1660 Ti which gives a very good ratio price/performance (especially for integer calculation) VanitySearch.exe -gpu -t 0 1testme
VanitySearch v1.13
Difficulty: 888446610539
Search: 1testme [Compressed]
Start Mon May 13 08:35:35 2019
Base Key: CBCC3BD678704956F2126B5B1346102F315D3271B83545A55C160324E98F52BF
Number of CPU thread: 0
GPU: GPU #0 GeForce GTX 1660 Ti (24x64 cores) Grid(192x128)
961.319 MK/s (GPU 961.319 MK/s) (2^35.46) [P 5.16%][50.00% in 00:09:51][0]
|
|
|
|
Is there a way I can estimate how many hashing attempt it would take, on average, to solve a hashing problem?
A hash function can be seen as a pseudo number generator. In the case of a 256 bit hash, the hash will produce a random number uniformly distributed in the range [0,2^256-1]. So depending on the minimum hash value you want you can compute the actual difficulty (from the number of acceptable hash) and deduce the probabilty to find a match after n tries using Bernouilli. 1-(1-number of acceptable hash/2^256)^n The BTC difficulty (displayed on www.blockchain.com) is computed as (actual difficulty/2^32). |
|
|
|
Well I just added more symbols to wildcard match function in Wildcard.cpp/GPUWildcard.h for finding exact patterns I want. It's very easy to do. I shared my one https://github.com/skipper70/VanitySearchI guess it's not a good way to go for production because we should write own regex on next steps =D Nice work As you seem to be familiar with the code, if you want to implement the regexp, fell free to send pull request  |
|
|
|
|
Hello,
I published a new release with a fix to prevent generation of segwit addresses using uncompressed keys which is invalid.
I never use uncompressed address so i totally missed this.
|
|
|
|
Many thanks for the tests Thanks to everybody for helping me to make this software better |
|
|
|
I put up a website listing all the bitcoin addresses with balances, sorted from the most to the least, https://bitkeys.workYou can see, the top address has 122K BTC in it. You can try to vanitygen your addresses by targeting those address, and good luck in some years. Nice It could be interesting to have the public key (if exposed) instead of a random priv key. Which is for instance the case for the first address with 122,804BTC: Pubkey: 03c931af9f331b7a9eb2737667880dacb91428906fbffad0173819a873172d21c4 Addr (Segwit 1x1 p2wpkh-p2sh): 385cR5DM96n1HvBDMzLHPYcw89fZAXULJP |
|
|
|
New release is online: Release 1.14 - Wildcard search - Case unsensitive search - Use of crypto secure random number generator for seeding Thanks for testing |
|
|
|
|
Thanks for the report.
I will publish the release as it is.
I also experimented issue with firefox running in concurrence with VanitySearch. VanitySearch uses the GPU at ~100% and from time to time Firefox requires lots of GPU power. A problem appears here when the GPU is too much used, it may fall into timeout and the OS try to recover which may result in system freezing. Very difficult to handle...
|
|
|
|
|
Thanks
Could you try: VanitySearch.exe -t 0 -g 16 -gpu 1*1111
|
|
|
|
Thank you.
Hope to find solution for issue with my GPU. Feel free to contact. I will do everything what I can.
Could you give me the output of command that generate the performance/hanging problem ? |
|
|
|
|
Show Posts
