 Show Posts
|
|
Pages: « 1 2 3 [4] 5 6 »
|
|
How many bytes of memory do you need to store one babystep? Hashtable uses GPU memory or global ram?
|
|
|
|
If you so cool WP, yor script can find a privkey for 02dd4127ed0232dcf6919e1cbf40562eeb6f050e0cc8663a576482100a51c116fa  Range only from 1:2^84 ?? If someone find my privkey he get 500$ in btc
??
ASAP please.There are many GPU renting services across the internet, you can rent power GPU for one hour and find this key spending just a few bucks. If you're so sure you've found the correct key and the correct range this time, why would you ask anyone to find it? |
|
|
|
Thanks for explaining this in concise terms.
Amazing how I thought this whole conjuncture was BS until someone actually came along with a proper demonstration.
The question now is how much more effective will this be vs. just dividing the keys?
i think these methods won't speed up 120 and further solution with Kangaroo or BSGS, because mathematically this is the same as dividing the original range to X parts and check them all for orginal pubkey. |
|
|
|
There is still one problem with this though, all the range beginnings are still much larger than the range end (assuming you're not simply adding length of #120 to it, if you're just dividing it by 33 or something it's guaranteed to be much smaller).
I'm already explained that all ranges will be X (X - divisor) times smaller than original range FFFFFFFF / 33 = 7C1F07D
(45d1745d1745d1745d1745d1745d1745d1745d1745d1745d1745d1741745d06a + 7C1F07D) = end of range |
|
|
|
3 x 45d1745d1745d1745d1745d1745d1745d1745d1745d1745d1745d1741745d06a = beginning of the range
then ffffffff divided by 33 + begin of the range marks the end of the range?
FFFFFFFF / 33 = 7C1F07D (45d1745d1745d1745d1745d1745d1745d1745d1745d1745d1745d1741745d06a + 7C1F07D) = end of range and if you search all 33 ranges, one of it will contains the key which you got when divided target key by 33. |
|
|
|
@Counselor
Well, you have to know the range, were you assume the privatekey. So how do you determine that range?
How do you know to search in D1745D1745D1745D1745D1745D1745D06A31FA8E3252B1A53FDAAA73xxxxxxxxxxxxxxxx?
If we use 33 as divisor, than to determine beginning of each range you have to multiply numbers (1 .. 33) to inverse(33, secp256k1.p) therefore you will get 33 possible ranges beginnings: 1 6c9b26c9b26c9b26c9b26c9b26c9b26c9b26c9b26c9b26c9b26c9b265d174433
2 d9364d9364d9364d9364d9364d9364d9364d9364d9364d9364d9364cba2e8866
3 45d1745d1745d1745d1745d1745d1745d1745d1745d1745d1745d1741745d06a
4 b26c9b26c9b26c9b26c9b26c9b26c9b26c9b26c9b26c9b26c9b26c9a745d149d
5 1f07c1f07c1f07c1f07c1f07c1f07c1f07c1f07c1f07c1f07c1f07c1d1745ca1
6 8ba2e8ba2e8ba2e8ba2e8ba2e8ba2e8ba2e8ba2e8ba2e8ba2e8ba2e82e8ba0d4
7 f83e0f83e0f83e0f83e0f83e0f83e0f83e0f83e0f83e0f83e0f83e0e8ba2e507
8 64d9364d9364d9364d9364d9364d9364d9364d9364d9364d9364d935e8ba2d0b
9 d1745d1745d1745d1745d1745d1745d1745d1745d1745d1745d1745c45d1713e
10 3e0f83e0f83e0f83e0f83e0f83e0f83e0f83e0f83e0f83e0f83e0f83a2e8b942
11 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa9fffffd75
12 1745d1745d1745d1745d1745d1745d1745d1745d1745d1745d1745d15d174579
13 83e0f83e0f83e0f83e0f83e0f83e0f83e0f83e0f83e0f83e0f83e0f7ba2e89ac
14 f07c1f07c1f07c1f07c1f07c1f07c1f07c1f07c1f07c1f07c1f07c1e1745cddf
15 5d1745d1745d1745d1745d1745d1745d1745d1745d1745d1745d1745745d15e3
16 c9b26c9b26c9b26c9b26c9b26c9b26c9b26c9b26c9b26c9b26c9b26bd1745a16
17 364d9364d9364d9364d9364d9364d9364d9364d9364d9364d9364d932e8ba21a
18 a2e8ba2e8ba2e8ba2e8ba2e8ba2e8ba2e8ba2e8ba2e8ba2e8ba2e8b98ba2e64d
19 f83e0f83e0f83e0f83e0f83e0f83e0f83e0f83e0f83e0f83e0f83e0e8ba2e51
20 7c1f07c1f07c1f07c1f07c1f07c1f07c1f07c1f07c1f07c1f07c1f0745d17284
21 e8ba2e8ba2e8ba2e8ba2e8ba2e8ba2e8ba2e8ba2e8ba2e8ba2e8ba2da2e8b6b7
22 55555555555555555555555555555555555555555555555555555554fffffebb
23 c1f07c1f07c1f07c1f07c1f07c1f07c1f07c1f07c1f07c1f07c1f07b5d1742ee
24 2e8ba2e8ba2e8ba2e8ba2e8ba2e8ba2e8ba2e8ba2e8ba2e8ba2e8ba2ba2e8af2
25 9b26c9b26c9b26c9b26c9b26c9b26c9b26c9b26c9b26c9b26c9b26c91745cf25
26 7c1f07c1f07c1f07c1f07c1f07c1f07c1f07c1f07c1f07c1f07c1f0745d1729
27 745d1745d1745d1745d1745d1745d1745d1745d1745d1745d1745d16d1745b5c
28 e0f83e0f83e0f83e0f83e0f83e0f83e0f83e0f83e0f83e0f83e0f83d2e8b9f8f
29 4d9364d9364d9364d9364d9364d9364d9364d9364d9364d9364d93648ba2e793
30 ba2e8ba2e8ba2e8ba2e8ba2e8ba2e8ba2e8ba2e8ba2e8ba2e8ba2e8ae8ba2bc6
31 26c9b26c9b26c9b26c9b26c9b26c9b26c9b26c9b26c9b26c9b26c9b245d173ca
32 9364d9364d9364d9364d9364d9364d9364d9364d9364d9364d9364d8a2e8b7fd
33 1 Size of the resulting ranges will be 33 times smaller than original, so you can calculate end of each range. In our case WP searched this range: 3 45d1745d1745d1745d1745d1745d1745d1745d1745d1745d1745d1741745d06a To be honest, I don't know how and what exactly WP calculates, but that is main idea of such key reduction. |
|
|
|
You set the range 1:ffffffff and you get a private key D1745D1745D1745D1745D1745D1745D06A31FA8E3252B1A53FDAAA7335FF288C D1745D1745D1745D1745D1745D1745D06A31FA8E3252B1A53FDAAA7335FF288C is bigger than ffffffff. Atleast in my math world  what does the size of the key have to do with it, if to find it you need to search a range 33 times less than the original, for example from D1745D1745D1745D1745D1745D1745D06A31FA8E3252B1A53FDAAA7300000000 to D1745D1745D1745D1745D1745D1745D06A31FA8E3252B1A53FDAAA75FFFFFFF |
|
|
|
30240 came from astro
360 days in year
7 day in week
12 month in year
360 x 7 x 12 = 30240
Full ver
2520
360 x 7 = 2520
For complete numerology 30240 will work
2520 will make u stuck in some part of calc
I don't want to upset you, but there are 365 days in a year |
|
|
|
Giving you all one more tip , in total numerology, only 30240 is is dividable from 1 to 10, mean 5 even 5 odd, at same time, and no floating result
I don't know what you mean by "numerology", but 30240 is not the only such number (some people already told about it) if you multuply 30240 to any numbers, and result could also div by 1 to 10, and in result no floating point
If you multiply any X by any Y, that resulting number will be divisible without remainder by all factors of Y (and X). There is no secrets. That is basics. Fundamental theorem of arithmetic. |
|
|
|
I apologize in advance for asking, but is it possible to check which of two points is greater? k number of one point is known.
If it were possible, the ECDLP problem would not exist |
|
|
|
If you don't mind could you explain it a little bit more? Or share me a link with useful content, if you're out of time.
Simple explanation. Let's take a number like 0.5 What is 0.5? It is half of 1, so this number, then multiplied by two, will give 1. Now we will find a number that satisfies this in the conditions of a finite field. It will be "7fffffffffffffffffffffffffffffff5d576e7357a4501ddfe92f46681b20a1" - if you double that number in secp256k1, you will get 1. So this enormous number also works just like 0.5. You may try it yourself with some EC calculator, just get a point from this privkey, then double it, you will get point from key "1". Some way we can explain "-1" as "fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364140" -1 + 1 = 0. If you add "1" and "fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364140" you will get point at infinity, that is works on EC like zero. |
|
|
|
Excuse me for the noob question: Let's assume x3=1, which means y2=8. What's y? Will it be square root of 8?
It will be square root modulo prime of 8 to be precise, it will be 29896722852569046015560700294576055776214335159245303116488692907525646231534 (29896722852569046015560700294576055776214335159245303116488692907525646231534 * 29896722852569046015560700294576055776214335159245303116488692907525646231534) mod secp256k1.p = 8 |
|
|
|
the public key in hex for this address is 049663999D864D6D1A79FFB0C547D19CB5A51123888AD4BDAE5CCEDB61CC3239BA4182C2088B09D 67ADEDF1BDC543B5F336D017017FF8D83E44D75A00A3D6BEE
i read it from other post
This public key belongs to 1BbBEt3uuNTo867wXnD2p4iv478Tcs3h1H and 1FG37pnmz9WPB413hMnn3VZEg3nF2QkUPA addresses |
|
|
|
Yes...but what I would really like to understand is why private key 3 needed to invert the y value and private keys 1 and 2 didn't need to invert the y value.
Why do there have y values that need to be inverted and other values that don't need to be inverted?
What math or method is used to know whether or not I will need to invert the y value?
If you're using standard EC math, there no need to invert anything. The point on the elliptic curve is generator point G multiplied by the private key. The EC multiplication formula calculates both X and correct Y and does not require additional inversion. Looks like you're trying to calculate only X and then trying to calculate Y from that X with simple equation, which leads to two possible solutions of that equation. And without using the multiplication formula, there is no way to know whether the right Y will be even or odd. |
|
|
|
|
Each x coordinate corresponds to two y coordinates, because of square root.
To convert between Ys, you have to calculate y2 = (y1 - secp256k1.p) * -1. One of Y is even and another is odd.
To indicate which coordinate is needed, the compressed keys starts with 02 for even Y and 03 for odd Y.
|
|
|
|
|
Elliptic curve symmetry. Such a magic. Wow!
|
|
|
|
I am currently in the Quadrillions of Keys/s and still no luck with finding the 120 Puzzle... yet 
Ive used to be big into mining crypto so Ive got a huge farm of GPU's, Im currently getting around 809 Billion Keys/s on Kangaroo
What DP size are you using and how many DPs have you already found? |
|
|
|
I'm not sure of the significance of these numbers so maybe a backstory on how you came about these numbers could be useful. Does it make the overall search time faster? Those numbers are factors of secp256k1 modified order n = 115792089237316195423570985008687907852837564279074904382605163141518161494337 (prime number) n-1 = 115792089237316195423570985008687907852837564279074904382605163141518161494336 (composite number) factorisation of n-1 into primes: 2*2*2*2*2*2 * 3 * 149 * 631 * 107361793816595537 * 174723607534414371449 * 341948486974166000522343609283189 18051648 = 2*2*2*2*2*2 * 3 * 149 * 631 9025824 = 2*2*2*2*2 * 3 * 149 * 631 6017216 = 2*2*2*2*2*2 * 149 * 631 and so on I don't see any special magic here. In fact, BTC's real private key can be divisible by any prime number and also can be prime by itself. Due to the fact that secp256k1 is a cyclic group, we cannot check whether the result of dividing an unknown number (public key) is an integer or a fraction (in real math, outside of cyclic group), so we cannot make any meaningful conclusions from the results obtained. |
|
|
|
Now, you can also divide a key. If we know our key lies in the 2^24 range and want to drop it down to the 2^14 range, we can divide by 1024 (2^10) 2^24 - 2^10 = 2^14
But now we have 1024 pubkeys that we have to search for but 2^1000% one of those 1024 pubkeys is in the 2^14 range.
So if one wanted to drop from 2^120 down to 2^70 range, well....that's a lot of pubkeys to search for.
Subtraction is clear to me, and so is division somewhat, but why the need to search 1024 pubkeys after dividing by that number? What will all their values be set to, apart from the one pubkey which is still its original value? Because you dont know whether the secret key is divisible without remainder by 1024. If not divisible, result will be lie somewhere on an unknown segment of elliptic curve. Therefore, to reduce key in such a way you have to divide by 1024 not only secret key, but also key+1 key+2 ... key+1023, one of which will be divisible by 1024 and lie in the correct reduced range. |
|
|
|
|
