Topic: Pubkey scaling/subtracting/other tips for reducing search time - page 3. (Read 2272 times)

you just explained that it has already been spend found. whe testing that key or what, what addition to add if found to get the right pvk. address. thanks

What all I have to install to compile the hacked-up script because I keep getting errors when I'm trying to compile it?

I finally got around to testing my hacked-up script which you can copy here to check that it produces the correct results when you divide public keys by numbers. I was pleasantly surprised to find out that they in fact matched the list of pubkeys that @WanderingPhilosipher gave me a while back (for #120's pubkey divided by 30, including the division by zero).

That means we got at least one working method to do the division.

By dividing, you can increase the number of public keys in comparison to other methods. I don’t think anyone would ever give you the whole formula to do it correctly.

It's a simple test. I will run my script to generate 30 pubkeys (of #120s pubkey, mine will actually kick out 31 because I also print out the 0 fraction), not a power of 2. They are listed below:

~

Now you run your script/the script you posted and see if the lists match.

By dividing, you can increase the number of public keys in comparison to other methods. I don’t think anyone would ever give you the whole formula to do it correctly.

https://bitcointalksearch.org/topic/m.57386530


Just FYI, for my 2 cents, if you know the range a key lies in, or want to gamble and take a chance where you think the key may lie, then I think subtraction is better.

Like I said a few posts back; we will take #120 puzzle for example. The private key can only start with 1 of 8 possibilities: 8, 9, A, B, C, D, E, F

Let's say you think it starts with C. You can then take the pubkey and subtract by C00000000000000000000000000000. Let us now say for example purposes the private key is:
C23BD97E765A75F0D6D4A6C6B67221.

So for your search range, after subtracting the C000....would be 0:FFFFFFFFFFFFFFFFFFFFFFFFFFFFF

By subtracting, you went from a search range of 2^120 to 2^116; 16 times smaller the original search range. BUT if you guessed wrong and the key does not start with C, then you will not find the key.

Staying with the same example, if you thought it started with C, D, E, or F and you subtracted by C000....then you could search the range of:
0:3FFFFFFFFFFFFFFFFFFFFFFFFFFFFF, and now you've went from 2^120 down to 2^117, 8 times smaller. BUT again, if the key does not start with C, D, E, or F, you won't find the key.

Dividing is fascinating because in your mind you see a much smaller search range, BUT the amount of pubkeys you have to search GROWS the smaller you cut the search range.

So I understand you subtract C00000000000000000000000000000 from 02CEB6CBBCDBDF5EF7150682150F4CE2C6F4807B349827DCDBDD1F2EFA885A2630 the public key for 120 and for example if you wanted to search F then you would subtract F00000000000000000000000000000 from 120 public key? and then search the same range 0:FFFFFFFFFFFFFFFFFFFFFFFFFFFFF
Correct.
------
i was thinking last night that we treat each keyspace as if they were  separated by a wall but they are not so i measured the distance between 115 and the center of 60 then reduced the public key of 115 by that amount. i hit the 115 public key ( i scanned a thru f on 60 and about one hour later I got a hit. Key found privkey fc07a1825367bbc
Publickey 0242257a130fe109c25c2ca6c60af60e5849305f77370401299b63da2094ec0297 and the addition  + 31464123230573851029232324144930570 . Trying it on 120 but so far no luck. i wish I had this kind of luck on 120 or the powerball lol. I have a image of the hit but don't think I can post it. The addition goes to the private key found
Awesome!

i was thinking last night that we treat each keyspace as if they were  separated by a wall but they are not so i measured the distance between 115 and the center of 60 then reduced the public key of 115 by that amount. i hit the 115 public key ( i scanned a thru f on 60 and about one hour later I got a hit. Key found privkey fc07a1825367bbc
Publickey 0242257a130fe109c25c2ca6c60af60e5849305f77370401299b63da2094ec0297 and the addition  + 31464123230573851029232324144930570 .

...

So the center of 60, which was what, in your calculation? so you took 115 - minus middle of 60 = x and subtracted x from original 115 pubkey, right?
And then you did a search in the 2^60 range?

You can't. Also as WanderingPhilosipher mentioned in a linked thread, you have to be careful not to divide by too much, or you will actually increase the number of group operations that you have to do and increase the runtime. 2^60 is way too much, even 2^20 makes the number of group ops bigger than a single 2^120 key.

TELL  ME PLEASE SOMEONE, HOW TO SUBSTRACT OR DIVIDE PUBKEY FROM for. ex. 120 TO 60 BITS WITHOUT GENERATING PUBLIC KEY IN AMOUNT 2^60 OR IN AMOUNT (2^120 - 2^60) ?

80 GIGABYTES OF PUBLIC KEY'S IS DRAMATICALLY UNUSABLE !!!

REGARDS !!!

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?  

I did a test run here: https://pastebin.com/raw/QZj7VSa3

I tried scrolling down from different spots. And I tried these different points with Puzzle 120. The result is negative.

2   447   7572   564114
3   596   9536   752152
4   631   10096   1128228
6   894   14304   1504304
8   1192   15144   2256456
12   1262   20192   3008608
16   1788   28608   4512912
24   1893   30288   6017216
32   2384   40384   9025824
48   2524   60576   18051648
64   3576   94019   
96   3786   121152   
149   4768   188038   
192   5048   282057   
298   7152   376076   

This discussion was forked from the various Bitcrack, VanitySearch, and Kangaroo threads about public key scaling.


Yeah that part was obvious to me, since in order to shift down by a bit you have to multiply the total number of result pubkeys by 2, effectively increasing the power.

The thing is that 260 and 720 are not powers of two so it would be helpful if brainless could explain what he's doing here to get this result.

This discussion was forked from the various Bitcrack, VanitySearch, and Kangaroo threads about public key scaling.


Yeah that part was obvious to me, since in order to shift down by a bit you have to multiply the total number of result pubkeys by 2, effectively increasing the power.

The thing is that 260 and 720 are not powers of two so it would be helpful if brainless could explain what he's doing here to get this result.

Here is one tip, division equals twice as many pubkeys. Look at my post above, I can shift 16 bits down with the expense of only 2^15 keys, cutting the fat by half.
With brainless, who knows, he is a wizard at pubkey/range reduction.