 Show Posts
|
|
Pages: « 1 [2] 3 4 5 6 »
|
increase the search speed of the Pubkeys, dividing the search range.
First of all, let me make it clear that this script is slow and basic, I did it like this in order to explain the range division method.
If you want to apply it quickly, modify keyhunt or other c++ code before compiling to make it work with this method.
The method consists in changing the parameters of the curve by x,y of a higher point (for the script I used pk#100).
by default the curve uses pubkey #1
what works in sequence 1,2,3,4....
pubkey #100
which works in sequence 100,200,300,400....
if we want to find pk# 3922
in a range of 2000:6000
in the traditional way we would need to advance +1900 pubkeys
In this method we will only need 19 pubkeys (1900/100).
the database is done by subtracting 1 consecutively from the target pubkey (in my case I need to subtract( 1), 100 times because I chose pubkey pk# 100 as divisor.
The trick is in your ability to use fast databases, the more pubkey you store in the database, the higher the divisor will be, therefore the search range is smaller.
I currently don't have what it takes to code in C++ using the quick search methods, my resources are limited to the basics.
I currently don't have an up-to-date pc to do the relevant tests (the disadvantages of the third world).
However, later I will share faster methods, ECC tricks.
So basically, you talk about stride option in already existing tools. |
|
|
|
Here is what I found, I'm not a mathematician but this should work and it can bend elliptic curve or rather straighten it.
56900346571233247÷5 = 11380069314246649.4 + n/5 + n/4 = 11380069314246649, I just couldn't find any meaningful result before, but I have tried the above method and it works.
It seems we can just divide it after all, but this won't help much if private key is unknown, these things are like fire for a child when they see it for the first time.
I wanted to say a monkey when you perform a magic trick in front of him, have you seen how excited they get? Lol.
n works like zero in real numbers, n/x = n, n+x = x and so on. |
|
|
|
|
Yeah, if you know that K lies between A and B, you can subtract A from K, and thereby "reduce" the key, but any other subtractions is just a blind guessing.
As for the any number manipulations, secp256k1 operations obey all the basic math laws, i.e. A - 2*A = -A; A - -A = A+A; A+B+C = A + (B+C) = (A+B) + C; A*(B+C) = A*B + A*C and so on.
|
|
|
|
This is not JeanLucPons version of Kangaroo
this have a lot of unnecessary checks that slow down the process.
JLP uses assembly instructions to perform GPU computations, also overall process of jumping is pretty good optimized in my opinion. Can you please give an example of non-optimal computations in JLP code, by optimizing which we can get a such increase in speed? |
|
|
|
Example of a strange public key: 0400000000000000000000003b78ce563f89a0ed9414f5aa28ad0d96d6795f9c633f3979bf72ae8202983dc989aec7f2ff2ed91bdd69ce02fc0700ca100e59ddf3 0400000000000000000000003b78ce563f89a0ed9414f5aa28ad0d96d6795f9c63c0c686408d517dfd67c2367651380d00d126e4229631fd03f8ff35eef1a61e3c
Just like there is invalid private keys, specifically those after the key fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364140 .. there are also invalid public keys. The reason is there are pub keys that lie outside the curve. But i gotta agree that the mentioned pubs above are interesting, especially knowing that one of their addresses is a used one. The only thing I'm not so fond of is the idea of.trying to figure out a mathematical formula to solve the puzzle. Sometimes it's possible to find a pattern in chaos, but most times you can't.
These are perfectly normal public keys that lie on a curve. Their private keys are 7fffffffffffffffffffffffffffffff5d576e7357a4501ddfe92f46681b20a0 and 7fffffffffffffffffffffffffffffff5d576e7357a4501ddfe92f46681b20a1 |
|
|
|
Thanks for helping, it worked.
Here comes the interesting part, that this Kangaroo algorithm takes only 1 public key. which is like finding 1 drop in an ocean as someone quoted. What about finding 1 billion drops instead of 1? Thats my point, when I say that 1 billion public keys increase the probability by 1 billion times. Hence, I am convinced if this Kangaroo algorithm takes 1 billion public keys instead of 1, the chances of finding one would increase exponentially. What do you say?
Kangaroo algorithm is originally designed to search for a specific point (public key) and does not work with multiple keys. In the process of work, he already creates a lot of points, mathematically related with original point. Basically you need to generate a number of pubkeys equal to square root of range to solve the ECDLP. If we talking about range like 2^125 (current unsolved puzzle), you have to generate 2^63 pubkeys to solve it (no need to save them all, it is futher kangaroo optimizations called distinguished points) |
|
|
|
I'm genuinely interested in knowing what would happen if we generate the hash160 then ignore the last 30 out of its 40 characters then load only the 10-digit prefix into the bloom filter to look for it against our target h160 prefix(es). Does this only mean less memory used by the blf and that's that?
Bloom filter works exactly like this. It's a memory-time tradeoff. You can adjust the filter parameters so that it takes less memory, but in this case it will give more false positives. |
|
|
|
You know I was wondering, when I try to search for 7 char prefix by entering only 7 characters, and by searching for the full address I get the same speed and performance.
Unless programs such as vanity and bitcrack can magically turn 7 characters into a complete rmd160 hash and just search for the hash instead of address, then I can't see a reason as to why searching for full address and 7 char prefix would have the same speed.
According to you those tools decode the address we give them and then only search for the rmd160, decoding the prefix of an address gives no clue about the actual rmd160 hash of said address, therefore they all are hashing the rmd160 twice with sha256 algo in order to find the correct checksum, hence slowing down the process.
VanitySearch checks the full address (i.e. performs full hashing) only if the given prefix matches, and before that it calculates and works with ripe160 only. I didn't delve into the bitcrack algorithm much, but I know for sure that it decodes given addresses into ripe160. |
|
|
|
|
I don't clearly understand what needs to be tested. If the question is "does the given public key lies in given range" than the answer is no, it doesn't.
|
|
|
|
i need this adderss privatekey
Uncompressed Address
1B5USZh6fc2hvw2yW9YaVF75sJLcLQ4wCt
Public Key (hex) 04c994b69768832bcbff5e9ab39ae8d1d3763bbf1e531bed98fe51de5ee84f50fb483ada7726a3c 4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8
AC9C52B33FA3CF1F5AD9E3FD77ED9BA4A880B9FC8EC739C2E0CFC810B51283CE |
|
|
|
I am not able to find the PrivateKey  it just says done, is it a bug or am i doing something wrong? Your key is on the edge of provided range. This is the hardest option. It will still be found, but it will take more time and more luck. [96.67 MK/s][GPU 0.00 MK/s][Count 2^33.51][Dead 2][02:26 (Avg 01:35)][47.6/81.5MB]
Key# 0 [1S]Pub: 0x029E162328C08BF1B3C9BA030ACBDBE111D1191D07A157AB285A403A739E5F0139
Priv: 0xE9C742148F3F0C84463F29FE66E2CA |
|
|
|
why it works?
Because when checking the signature, only the x-coordinate is checked, and since due to symmetry there are two points with the same X, there are two different private keys that lead to the same solution. To calculate the second possible key, it is enough to take a symmetrical nonce. With your parameters from the example: r= 69933057925445156103627311546056983351587171473600111963597898281808348149939
s= 99514802695095857543902537284008490009261385852143431210120625655251582757337
z= 12948693844049826047046411457108709640188688022302896372272988915976703455562
nonce= 76658540346477621248539633331872761318528094222023647613764244410682868036596
nonce_sym = (nonce * (n-1)) % n
priv1 = (modinv(r,n) * ((nonce * s) - z)) % n
print(priv1) #664613997892457936451903530140172288000
priv2 = (modinv(r,n) * ((nonce_sym * s) - z)) % n
print(priv2) #110623181588558332205237110447978292605510900347349684371947434845384786316778 |
|
|
|
FYI: https://gcd.cr.yp.to/papers.htmlThe fastest modular inversion with constant time that I know. About 4000 CPU clock cycles per inversion. Also check "software" tab for avx-optimized example sources. It can be optimized further but at the cost of constant time implementation. |
|
|
|
|
These are completely different algorithms and it is incorrect to compare them by the numbers shown. A properly tuned kangaroo will always run faster than BSGS.
However, the main difference is that if the BSGS did not find the key and finished work, then you can be sure that the key is not in the given interval. Kangaroo is a probabilistic algorithm, and you cannot be sure that there is no key in interval, even if the kangaroo has completed the estimated number of operations.
|
|
|
|
what does it need to make the RTX 4090 compatible with tools like VanitySearch, BitCrack, etc... ? Is this something we can fix ourselves by just adding a particular ccap file into the sources of the program so it can compile? Or does it need something on CUDA side? Any clues ?
It's the compiler that doesn't support the 8.9 compute capability, not the program. Just upgrade CUDA toolkit to version 11.8 or newer. |
|
|
|
So, to test number N you need N+2 add/sub operations. Isn't it easier to just iterate over all the points from 1 to N?  |
|
|
|
How the fuck do you create an address like this?
Seems someone can crack the code so he can do what he wants?
This address - 1111111111111111111114oLvT2, created from RIPE160 hash with all zero bits "0000000000000000000000000000000000000000" Because there is no known attacks on ripe160, it is nearly impossible that someone found such input, that will produce that hash, even if you do not take into account double hashing when generating an address. To get this address, you have to find a such EC point, that will produce such SHA256 hash, which in turn will produce 160 zero-bits RIPEMD. So, 1111111111111111111114oLvT2 is valid BTC address, but no one knows its key, and it may well be that such a key does not exist at all. |
|
|
|
|
I don't know any ready-to-use 256bit number numpy libraries, but it is possible to create one, using 64 or 32bit numbers for math operations.
You cannot just speed up individual operations like point multiplication by using GPU, because single CUDA core is much slower than CPU. You need to divide full computing work into many independent tasks which will run in parallel in order to get the performance gain.
|
|
|
|
You can't do 1809251394333065553493296640760748560200586941860545380978205674086221273349 operations in several hours either.
I don't have any reason to doubt that you've listed a number of points related by doubling, but the claim that you were able to wrap around and enumerate all of them from any starting position and then moving in one direction (either doubling or halving) can't be true, AFAICT.
He doesn't talking about mapping all points, which can be generated by doubling/halving. As I understand it, he found a sequence of keys that are generated in this way and leads to the used addresses. It looks like a manual generation of something like HD wallet with bad realisation. Something like if you take first address key ("master key") and derive other wallet addresses just by doubling "master key" N times. It is obvious that such an algorithm, unlike a normal HD wallet, allows you to recover the keys to all addresses, if you know any one of them. |
|
|
|
as for 20m halve required too much time, for this i create an other thread, for discus this issue, where i ask developer, just for basic add/sub/mul conversion creator/generator by pycuda or cuda tools , when said tools available, these job are for seconds for millions point https://bitcointalk.org/index.php?topic=5409721.0If you need 50k keys by sequential halving the original, why use expensive division on each step, you just can take "last" key (original / 2^50000), and then generate all keys by fast doubling. |
|
|
|
|
