 Show Posts
|
|
Pages: « 1 2 [3] 4 5 »
|
RTX 4070 Ti compute capability 8.9 1. Update/Install CUDA toolkit 12.3 2. Add this code in GPUEngine.cu: {0x75, 64},
{0x80, 64},
{0x86, 128},
{0x87, 128},
{0x89, 128},
//{0x90, 128},
{-1, -1} };
In file VanitySearch.vcxproj replace CUDA 10.2.props and CUDA 10.2.targets to CUDA 12.3.props and CUDA 12.3.targets 3. In project properties -> CUDA C/C++ -> DEVICE -> CODE GENERATION -> add: compute_80,sm_80
compute_86,sm_86
compute_87,sm_87
compute_89,sm_89
Apply -> OK 4. Choose Build Solution from the Build menu Visual Studio. Or linux build: make gpu=1 ccap=89 all It seems so  |
|
|
|
These are all games for small children, no matter how you turn the ball, the result is small.. It seems it’s time for everyone to stop with long posts. Spin the ball in the other direction  , like this: void VanitySearch::setSeed(int thId, bool fl) {
// Setup rseed() of unix time
unsigned long Timestamp_min = 1262293200;
unsigned long Timestamp_max = 1672520400;
unsigned long ts = (unsigned long)time(NULL);
ts = ts + (unsigned long)thId;
ts = ts + ts_output;
while (ts < Timestamp_min || ts > Timestamp_max) {
ts = (ts * 54321) % Timestamp_min;
if (ts == 0) ts = (unsigned long)time(NULL);
ts = (ts * 12345) % Timestamp_max;
if (ts == 0) ts = (unsigned long)time(NULL);
}
if (fl) { printf("\n[i] Time Unix: %u \n", ts); }
rseed(ts);// Set seed
ts_output = ts;
//
}
Using the original Random.cpp |
|
|
|
Thanks. Btw...We don't need such a long seed lenght - even 9 gets the job done. // Seed
if (seed.length() == 0) {
// Default seed
seed = Timer::getSeed(9);
}
if (paranoiacSeed) {
seed += Timer::getSeed(9);
}  You changed the wrong seed. New Seed begins with a capital letter
//Set startKey from Seed
int BitL = Random_bits - 1;
int BitU = Random_bits;
Int *Sk = new Int[1];
if (Seed.length() > 0) {
// from Seed
getKeysFromRandomSeed(BitL, BitU, true, 1, Sk);
startKey.Set(&Sk[0]);
printf("[i] startKey.Set() from Seed: %s \n", Seed.c_str());
//
}
delete [] Sk;
//
// argv Seed
if (Seed.length() == 0) {
// Default seed
seed = Timer::getSeed(32);// random seed
} else {
seed = Seed;// -s seed
}
Be careful! Previously, the old one was just for starters. Next is the code startKey.SetInt32(0) |
|
|
|
Also, explain how any of these seeds or different random options actually help?!
Even if one random option is faster by 9 million percent, which would still be minimal in the scheme of things, the hard work still has to be done, taking the private key and transforming it down to the H160.
My VBC random is fast; finds a key in a 36 bit range in an avg of 8 seconds. User has option to choose a range or simply enter a bits number such as 66.
However, the generation of the random key, and its speed, really doesn’t matter IMO. It takes less than .4 seconds to generate thousands of keys, and yet, the actual computation must begin…the actual work.
If loop the seed generation until the Starting key is equal to the target key puzzle bit 32. This takes a long time. We need to know not only the seed. what algorithm was used and the number of rounds. Therefore, I created a function for separating a 512-bit key, one was used as a master key, the other as a chain key. There you can also add serialization and make several keys from a chained key. And make them starting keys. This time is again needed to create the code.
/* Magic Mersenne Twister constants */
#define N 624
#define M 397
#define MATRIX_A 0x9908b0dfUL
#define UPPER_MASK 0x80000000UL
#define LOWER_MASK 0x7fffffffUL
Technical Description CVE-2023-39910
The cryptocurrency wallet entropy filling mechanism used in Libbitcoin Explorer 3.0.0–3.6.0 is weak, also known as the Milk Sad problem. Using the Mersenne Twister mt19937 PRNG limits the internal entropy to 32 bits regardless of settings. This allows remote attackers to recover any wallet private keys generated from the entropy results of “bxseed” and steal funds. (Affected users need to transfer funds to a new secure cryptocurrency wallet)
is this issue present still in your vanitygen, thanks for the exes.
I know this very well; this protocol was developed a long time ago. Why are you telling me this again??? 1. This piece of software code is present, AND IT IS NOT USED. For this, OpenSSL and other key generation functions were added. Read the background of this fork! What's added there? And what was removed there on purpose. And why was all this done? 2. Regarding the exe, it has already been explained to you. Don't be pushy. You need to put in the effort if you want results. The values of random keys fixed by the rseed(seed) function are used to check for possible mathematical errors and the correct assembly of the code by the compiler. The constant values used to check the correctness of calculations and speed tests are also present in the GPU code. If these Magic Mersenne Twister constants macro definitions are confusing, you can change the code in Engine.cu - remove rseed(seed) and Rand(256). Opt out of the GPU test. |
|
|
|
Am I understanding this correctly that you have found seed collisions? Because I see different seeds with the same key as output, or is this something else?
This is not a collision. The one that was used is saved. With the -r 1 option you can select the fastest one. If we get lucky. |
|
|
|
Should add seed to be written in Results.txt fprintf(f, "PubAddress: %s\n", addr.c_str());
fprintf(f, "Seed: %s\n", seed.c_str()); Something like this. So that we can reproduce the same result Experiment with the least significant bits up to 2^30, which seed is more suitable in terms of solution speed. I like your ideas  Added new code to mods on Github. Saving Seed to the Result.txt file. Then run with the -s option. Seed for mod 006, key generation methods are different. VanitySearch.exe -stop -t 1 -bits 28 -r 1 -s 45730C0CCA52F09AC21B00E4ADA360E9709152473494E91DFD74B6E11938BF30 12jbtzBb54r97TCwW3G1gCFoumpckRAPdY
The installed SEED works if the -r (rekey) option is present. Updated. Without the -r (rekey) option, the start key is selected with the -start option OR -s option and use -bits option. file Result.txt Seed: 45730C0CCA52F09AC21B00E4ADA360E9709152473494E91DFD74B6E11938BF30
PubAddress: 12jbtzBb54r97TCwW3G1gCFoumpckRAPdY
Priv (WIF): p2pkh:KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M82GSgY8p5EkUe
Priv (HEX): 0xD916CE8
Seed: B6D88248ED9FA96F42684121433DCACEB655BF37E0B65C007E58D0AD59ADECBF
PubAddress: 12jbtzBb54r97TCwW3G1gCFoumpckRAPdY
Priv (WIF): p2pkh:KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M82GSgY8p5EkUe
Priv (HEX): 0xD916CE8
You can reproduce the result |
|
|
|
That's something.
1 / 0.00011618 = 8607 Keys/s. But in fact it is more. To reduce measurement time, you need to generate more than 10,000 hashes in a cycle, preferably tens of millions. Then the measurement time is not actually counted, and the result will be more plausible. |
|
|
|
now alek, can you send a exe to pm or github. thanks man.
The program takes exactly 1 minute to assemble. These mods don't need OpenSSL, you don't have to build it if it's difficult for you. Just replace Int.cpp, Int.h and Random.cpp, Random.h with the original ones and comment out the lines #include <openssl.... The original files are in the root directory. I think it's worth learning how to assemble programs. Understand correctly, I can’t keep up with all the adjustments. In essence, this is a branching of the code; for this purpose, the “mod” directory has been added. |
|
|
|
Cool features.
I peeked into your random bits code and it is wonky. A lot of code to make sure it falls within the 2000…3FFF… (66 bitrange)
But it’s reliable, let him check) There, he also added cleaning to prevent memory leaks. You can change the algorithm in mod 006. After the random seed, do the sha256 function and then the HMAC-SHA512 function. The number of rounds can be set to any value. here - #define hmac_sha512_nb_round 2048. I think the mod 005 algorithm is better, I like it better) |
|
|
|
Hi again everyone. I added mods with different ways of generating keys. The getKeysFromRandomSeed() function is made in two versions, located in folders 005 and 006, respectively. Just replace the files and rebuild the project. https://github.com/alek76-2/VanitySearch/tree/main/mod/005https://github.com/alek76-2/VanitySearch/tree/main/mod/006logs: VanitySearch_bit66_hb03.exe -stop -t 1 -bits 66 -r 10 -level 0 13zb1hQbWVsc2S7ZTZnP2G4undNNpdh5so
[ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ]
[ ]
[===========================================================]
[ Changes by Alek76 modify 0.05 ]
[===========================================================]
[ Tips: 1NULY7DhzuNvSDtPkFzNo6oRTZQWBqXNE9 ]
[===========================================================]
[ Options added argv [-start] [-bits] and disable SSE ]
[ ]
[ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ]
Difficulty: 1461501637330902918203684832716283019655932542976
Search: 13zb1hQbWVsc2S7ZTZnP2G4undNNpdh5so [Compressed]
Start Sat Nov 4 19:48:20 2023
Base Key: Randomly changed every 10 Mkeys
Number of CPU thread: 1
[i] Generate Keys HMAC-SHA512 1024 Rounds From Random SEED
Bit 66 CPU Base Key thId 0: 3E83B482ABFAF4B33
[1.08 Mkey/s][GPU 0.00 Mkey/s][Total 2^23.37][Prob 0.0%][50% in 2.97319e+34y][Found 0]
[i] Generate Keys HMAC-SHA512 1024 Rounds From Random SEED
Bit 66 CPU Base Key thId 0: 38C4111B5590EB61D
[1.03 Mkey/s][GPU 0.00 Mkey/s][Total 2^24.33][Prob 0.0%][50% in 3.11891e+34y][Found 0]
[i] Generate Keys HMAC-SHA512 1024 Rounds From Random SEED
Bit 66 CPU Base Key thId 0: 36524D9A4683DCF53
[1.03 Mkey/s][GPU 0.00 Mkey/s][Total 2^24.90][Prob 0.0%][50% in 3.11697e+34y][Found 0]
[i] Generate Keys HMAC-SHA512 1024 Rounds From Random SEED
Bit 66 CPU Base Key thId 0: 3DAEDA8D12C373053
[1.03 Mkey/s][GPU 0.00 Mkey/s][Total 2^25.16][Prob 0.0%][50% in 3.11948e+34y][Found 0]
|
|
|
|
You are right. To be more precise, we use the van Oorschot and Weiner Method of kangaroos.
I imagined if you use Gaudry Schost method (re-place a kangaroo at a new random point as soon as you hit a distinguished point) that you could have an advantage. Especially when using tame points in the target bitrange and wild points where one or many might not be in the target bit-range (e.g. when having many targets while experimenting with division). You would kind of saturate the tame DPs more and more while the chance to hit a DP with the wild range increases. But today I don't think it is of much use. You can move tame kangaroos like this: // Random Tame StartingKey range bnL - bnU
Int TameStartingKey;
Int tsk;
new_tsk:
tsk.Rand(pow2U);
if (tsk.IsLower(&bnL)) goto new_tsk;
TameStartingKey.Set(&tsk);
//
Int tkey;
tkey.Rand(pow2W);
keys[index].SetInt32(0);
keys[index].Add(&TameStartingKey);// Tame keys
keys[index].Add(&tkey);
|
|
|
|
puzzle 130 private key is even number Well, tell me how you know this? |
|
|
|
I will build out any script. Tell me your ideas and i will build. anyone interested PM. you may have an idea that can lead to victory, may not be sure how to write the program. I've got you. it may be taking forever because a great idea hasn't been built out yet  If you can  , then write a script that will determine the parity of the public key
How can or might this be useful? When it comes to Kangaroo method, I think people over think it. You just need to find as many leading or trailing 0s (or any other hex character) as fast as possible.
The tame or wild range should be 1 range and the other should be throughout the range.
Find leading or trailing DPs, fast, set tame higher than wilds. It should be that easy.
Yes. Useful for dividing PK. Invert several random keys modulo N, then multiply them by the target PK. And then you drive it into a kangaroo. I checked it works. Divide by no more than 2^11, otherwise the probability of kangaroo work will be low. There may be several of them, all targets divided. But some goals are useless because the divisor is not suitable. |
|
|
|
Constants in GPU code - Get 64bits lsb negative inverse of SecpK1 order print 'GET MM64 Mod P'
invP = inverse_mod( -_p, (2**64))
MM64 = hex(invP)[2:-1]
MM64 = MM64.upper()
MM64 = '0x' + MM64 + 'ULL'
print MM64
print 'GET MM64_Order Mod N'
invP = inverse_mod( -_r, (2**64))
MM64o = hex(invP)[2:-1]
MM64o = MM64o.upper()
MM64o = '0x' + MM64o + 'ULL'
print MM64o
f = open('MM64.txt', 'a')
f.write('\n'.join(['#define MM64 ' + MM64 + '\n' + '#define MM64o ' + MM64o + '\n' ]))
f.close()
Result: #define MM64 0xD838091DD2253531ULL #define MM64o 0x4B0DFF665588B13FULL Once upon a time I added inversion modulo _N. It was not originally in the Int class. There you just need to change _P to _N. This is the Montgomery method. But you can also do it using the DRS62 method. Simply replace MM64 with MM64o and the inversion will be modulo _N (this Order). This function is necessary for dividing the Public key. // ------------------------------------------------
// add by alek76-2
void Int::ModInvOrder() {// Montgomery method
// Compute modular inverse of this mop _N
// 0 < this < _N , _N must be odd
// Return 0 if no inverse
// 256bit
Int _N;
_N.SetBase16("FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141");
Int u(&_N);
Int v(this);
Int r((int64_t)0);
Int s((int64_t)1);
//
Int x;
int k = 0;
// Montgomery method
while (v.IsStrictPositive()) {
if (u.IsEven()) {
shiftR(1, u.bits64);
shiftL(1, s.bits64);
} else if (v.IsEven()) {
shiftR(1, v.bits64);
shiftL(1, r.bits64);
} else {
x.Set(&u);
x.Sub(&v);
if (x.IsStrictPositive()) {
shiftR(1, x.bits64);
u.Set(&x);
r.Add(&s);
shiftL(1, s.bits64);
} else {
x.Neg();
shiftR(1, x.bits64);
v.Set(&x);
s.Add(&r);
shiftL(1, r.bits64);
}
}
k++;
}
if (r.IsGreater(&_N))
r.Sub(&_N);
r.Neg();
r.Add(&_N);
for (int i = 0; i < k; i++) {
if (r.IsEven()) {
shiftR(1, r.bits64);
} else {
r.Add(&_N);
shiftR(1, r.bits64);
}
}
Set(&r);
}
// ------------------------------------------------
This may be useful to you |
|
|
|
Has anyone tried to make Kangaroo in PHP? ... Share a Kangaroo MySQL database across the globe. (Peer-to-Peer) The number of manipulations does not increase the speed. It’s easier to make a converter from txt to sql. Let the PHP script look for a collision in the table. It’s even easier to make a list of text files and check them with a Python script. The simpler the faster, that's how it is. |
|
|
|
Why do you say this is a must?
DP with a mask works just as well and it doesn’t require an additional math step.
Because I previously read an article where Pollard's selected highlighted points with zeros at the end. And using a DP less than 16-18 will naturally slow down the speed. |
|
|
|
I don’t know, I achieved a speed of 520 Mkeys - this is with writing to a table, reading from a table and writing to files, and at the same time checking to find a solution.
Alek, as someone who is extremely familiar with your program, and have modified it over the years, it is a lot slower than JLPs, but it has certain benefits that I like, such as saving points to a text file. Possible ways to speed up your code; drop the modulo function to check for DPs and just use a mask like JLPs code. That may provide a speed up and also cause less erroneous points; these erroneous points happen a lot once the GPU has ran for hours. I’ll have to look at your updated code sometime in the near future to see all of your changes. But your Kangaroo GPU was the first & a trendsetter! if (px[g][0] % DPmod == 0) { // If you mean this? 1. I think that this is precisely the correct meaning. Yes, I tried using a mask (bitwise & operation) - it doesn't provide much of a speed benefit. Another mask is inverted and the "&" operation can add unnecessary points to the table. DP must be selected modulo!!! 2. The only problem is the time it takes to open a large file to write one line. That's why everything was so slow. With a table, even just with an Int *var array, everything happens much faster. I accumulated 1024 points, opened the file and wrote it down, and so on in a circle. There you just need to add a counter and conditions, rewrite the File2save() function. But I have already rewritten it, which I advise you to do as well. I agree this will take some time. Github has not been updated. After these changes, the speed increased. 3. The periods for preserving the working herd of kangaroos are set once every 10 minutes. Flags are set based on the timer, and based on the presence of flags, data from the GPU is uploaded to the array. Next, they are written from the array to the work file. Function SaveWorkKangaroosToFile(). And when the program is restarted, on the contrary, the start keys are not generated, but are unloaded from the file. Function LoadWorkKangaroosFromFile(). 4. Text files provide an advantage, since you do not need to process a large table with data every time. The table is cleared - this is also time. And the array can simply be rewritten. There is a difference? I saved a small file and spat it out to the server via a socket. That's all. And on the server there is a comparator that also runs on a timer. It seems like I've already told you a lot. Write the code - add it. I can tell you a secret that errors appear after several hours of work not because of the bit operation "%". They appear due to arbitrary data that initially hangs in the most significant bits. bits64[4] is more than 256 bits of data. Before putting data into the GPU, you need to check it. Declaring an Int while simultaneously assigning a value from another Int variable does not clear the high-order bits. This is the second time I’ve repeated myself and repeated myself. Int is first declared and then assigned a value. The .Set() operation does not clear the high-order bits. The SetInt32() and Rand() function clears. I say analyze the code. Even I, 3 years ago, did not have such care in the code. Everything should be fine now This could be your errors in the GPU or due to data overflow. No need to overload the GPU. Set GRP SIZE 64. The physical memory may also be bad - the memory chip itself ( or 1 of 8 ) . And so everything should be clean. |
|
|
|
Keep up your good work, you can do this, you can solve any key as long as you have the private key. Lol
Some of your posts are interesting. Thank you. And when the time comes, you begin to understand that you can spend it on learning C++ or on useless messages? I continue to develop my old program, which I started in 2020. I initially saved all DP data to a file. It takes a long time to open the file and write. Now I will add a Hash table for temporary aggregation of selected points and their subsequent recording to a file - this is faster. My saved data is 256 bits in size. I also save the working kangaroos to another file. For those interested, the function for loading and unloading a herd of kangaroos is in the backup.cpp file. https://github.com/alek76-2/vs-kangaroo-multi/blob/master/Backup.cpp Can be used. I will not publish other functions, at least for now, for obvious reasons. But if you want to solve 130, you'll have to rewrite Jean-Luc program because it has limitations. And not only in the GPU code, but also in the size of the data in the table itself. It’s not just that, having computing resources, download the finished code and solve 130. It’s even pleasing. Those who have resources have no knowledge. And those who have knowledge do not have resources. I don’t know, I achieved a speed of 520 Mkeys - this is with writing to a table, reading from a table and writing to files, and at the same time checking to find a solution. And added loading the herd from the file - when restarting. I’m still writing the code, even if I’m unlucky in solving the problem. And still. Everyone complains about the amount of energy wasted, but have you ever analyzed someone else's program code? To avoid wasting money... ./vs-kangaroo-multi -dp 16 -gpu -bits 64 03100611c54dfef604163b8358f7b7fac13ce478e02cb224ae16d45526b25d9d4d The forked software created 29.10.2023 by Alek-76 fixed modify v0.16 ...
make: warning: Clock skew detected. Your build may be incomplete.
[###########################################################]
[# Pollard-kangaroo PrivKey Recovery Tool #]
[# (based on engine of VanitySearch 1.19) #]
[# bitcoin ecdsa secp256k1 #]
[# ver. 0.16 #]
[# GPU implementation changes by Alek76 #]
[# Tips: 1NULY7DhzuNvSDtPkFzNo6oRTZQWBqXNE9 #]
[###########################################################]
[DATE(utc)] 29 Oct 2023 12:34:37
[~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~]
[pow2bits] 64
[Wsqrt] (2^31) 100000000
[M] C000000000000000
[~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~]
[i] Used OpenSSL Random number generator
[i] OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022)
[~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~]
[rangeW] 2^63..2^64 ; W = U - L = 2^63
[DPsize] 1048576 (hashtable size)
[~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~]
[pubkey#64] loaded
[Xcoordinate] 100611C54DFEF604163B8358F7B7FAC13CE478E02CB224AE16D45526B25D9D4D
[Ycoordinate] 5127C2D0B1C4A4D5B4996BBDF37633B86901D0303B61E2F6F0772282AE08FF95
[~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~]
[+] Sp-table of pow2 points - ready
[~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~]
[UV] U*V=0*0=0 (0x00)
[i] Old DPmodule: 2^29
[i] New DPmodule: 2^24
[+] 0T+0W kangaroos - ready
[CPU] threads: 0
[GPU] threads: 1 Hang on to your hats... ;-)
[i] Used Comparator in Python
===========================================================================
by Pollard (.. The best choice of m (mean jump size: 2^32) is w^(1/2)/2 ..)
[i] Used Mixed 16 Jump Table: G,2G,4G,8G,16G,...,Rand(2^pow2Wsqrt+1)
Create Jump Table (size: 16) Max Jump: 2^33
Jump Avg distance: 2^31.04 (+/- use option -p)
===========================================================================
GPUEngine: Fixed DPmodule = 2^16
GPUEngine: Total kangaroos and their close relatives 1310720 ;-)
GPUEngine: Fixed DPmodule: 0x10000 2^16 Hop_modulo: 32 Power: 0
GPUEngine: Stack Size: 1024
GPUEngine: Heap Size: 8388608
GPU GPU #0 Tesla T4 (40x64 cores) Grid(80x128) (129.0 MB used; GRP size: 128; nbSpin: 256)
[i] GPU TameStartingKey: C000000000000000
GPU thId: 128 GPU bnL: 64
GPU Tame Points: [M] + Rand(pow2W)
GPU Wild Points: [Target] + Rand(pow2W)
GPU Wild Starting Key 0: 4243657DAD16D786
GPU Tame Starting Key 1: 12318636040F76DBF
GPU Wild Starting Key 2: 5D33C0C3E0BBEACD
GPU Tame Starting Key 3: 12821E106B999205E
GPU Wild Starting Key 4: B2905822AFDE251
GPU Tame Starting Key 5: C14C17F1ADF64974
GPU Wild Starting Key 6: 27ABF855C19AFB16
GPU Tame Starting Key 7: 1148E716BA44257DB
GPU Wild Starting Key 8: 375F3D5C55AFDF84
GPU Tame Starting Key 9: DF8E0EA7009CA26F
GPU Tame Starting Key 1300480: E191DA8F160EC93C Kangaroos: 1310720
NB Thread: 10240 , GPU_GRP_SIZE: 128
[+] Runing Comparator every: 30 sec
Python Comparator time: 1256.725 msec
[\][ 0: 0:34 ; 566.1M j/s; [GPU 566.12 Mj/s] 18.0Gj 437.5%; dp/kgr=0.0; 0: 0: 0 ]
Python Comparator time: 3188.568 msec
[-][ 0: 1: 4 ; 524.2M j/s; [GPU 524.20 Mj/s] 34.0Gj 812.5%; dp/kgr=0.0; 0: 0: 0 ]
SOLVED: 0xf7051f27b09112d4
Tips: 1NULY7DhzuNvSDtPkFzNo6oRTZQWBqXNE9
[\][ 0: 1: 6 ; 524.2M j/s; [GPU 524.20 Mj/s] 35.0Gj 835.9%; dp/kgr=0.0; 0: 0: 0 ]
[i] No Cleaning wild and tame files
SOLVED: 0xf7051f27b09112d4
Tips: 1NULY7DhzuNvSDtPkFzNo6oRTZQWBqXNE9
[i] 550.9M j/s; 36.0Gj of 4.0Gj 859.4%; DP 0T+0W=0+0=0; dp/kgr=0.0;
[runtime] 0: 1: 7
[~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~]
[DATE(utc)] 29 Oct 2023 12:36:07
[~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~]
[x] EXIT
I don't know why the Jean-Luc Pons program checks for collision distance. It is necessary to check the coincidence of X coordinates. |
|
|
|
Everything is in division, forget about finding the exact divisor to just divide and land on a known key, you need to work with scalar and points side by side, meaning that you have to run 2 scripts (since I'm not a coder I do that), and then do the dividing PLUS, this is important, plus having a third operation which is subtraction, from there you can learn many things. As I have. Good luck guys, I have already found my tree in the middle of the ocean.😉
Absolutely right! But some “mathematicians” are trying to teach something new. The result of the division may be near the target key. And there are much fewer exact divisors, but they exist! Your tree works, I know it. The result using the 64-bit example is: BIT 64 key = (0x171cec757dceb3 * 0xAB0) - 0x63C These calculations are made from a 64-bit public key. I do it a little differently, just two programs. You just need to change the algorithm, 3 is a lot of scripts. One program for calculations and one program for solving the results - probably two at most. Although it can be different. |
|
|
|
Even from divisions with results with fractions (floats), you can obtain integers with certainty.
If you use mathematics correctly.
The comma can be moved in any direction, that’s not the issue. You need to work with integers. Can you do the same with the public key? Even if you can, it doesn't give you the range of the private key. |
|
|
|
|
