Author

Topic: Bitcoin puzzle transaction ~32 BTC prize to who solves it - page 118. (Read 215611 times)

member
Activity: 122
Merit: 11
Code:
Chunk 1 end 36893488147429103232:   0%|                                            | 0/10000000 [00:00Traceback (most recent call last):
  File "/home/zbigniew/seed1.py", line 24, in
    h160 = ice.privatekey_to_h160(2, True, x)
AttributeError: module 'secp256k1' has no attribute 'privatekey_to_h160'

Why it's not working ?


Because it is installed through pip
pip3 install secp256k1
you will  have
    h160 = ice.privatekey_to_h160(2, True, x)
           ^^^^^^^^^^^^^^^^^^^^^^
AttributeError: module 'secp256k1' has no attribute 'privatekey_to_h160'

it won't work because it's not the one. But custom from here:
https://github.com/iceland2k14/secp256k1


Thank you sir ! Now it works.
member
Activity: 462
Merit: 24
Code:
Chunk 1 end 36893488147429103232:   0%|                                            | 0/10000000 [00:00Traceback (most recent call last):
  File "/home/zbigniew/seed1.py", line 24, in
    h160 = ice.privatekey_to_h160(2, True, x)
AttributeError: module 'secp256k1' has no attribute 'privatekey_to_h160'

Why it's not working ?


Because it is installed through pip
pip3 install secp256k1
you will  have
    h160 = ice.privatekey_to_h160(2, True, x)
           ^^^^^^^^^^^^^^^^^^^^^^
AttributeError: module 'secp256k1' has no attribute 'privatekey_to_h160'

it won't work because it's not the one. But custom from here:
https://github.com/iceland2k14/secp256k1
member
Activity: 122
Merit: 11
Code:
Chunk 1 end 36893488147429103232:   0%|                                            | 0/10000000 [00:00Traceback (most recent call last):
  File "/home/zbigniew/seed1.py", line 24, in
    h160 = ice.privatekey_to_h160(2, True, x)
AttributeError: module 'secp256k1' has no attribute 'privatekey_to_h160'

Why it's not working ?
member
Activity: 93
Merit: 16
These are all games for small children, no matter how you turn the ball, the result is small..  Grin
It seems it’s time for everyone to stop with long posts. Spin the ball in the other direction   Roll Eyes, like this:
Code:
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
member
Activity: 462
Merit: 24

Thanks. Btw...We don't need such a long seed lenght - even 9 gets the job done.

Code:
 // Seed
  if (seed.length() == 0) {
    // Default seed
    seed = Timer::getSeed(9);
  }

  if (paranoiacSeed) {
    seed += Timer::getSeed(9);
  }

 Wink
You changed the wrong seed.
New Seed begins with a capital letter  Grin
Code:

  //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!  Grin Previously, the old one was just for starters.

Bit 19 Base Key thId 11: 5BF03 < 80000 or > FFFFF Rekey true

Bit 15 Base Key thId 6: 58C0 < 80000 or > FFFFF Rekey true

Seed: 31C0F9E7B08DB7B945

Seed: B79E1E04AAAC8DC9CE

Bit 20 CPU Base Key thId 11: A2C56

Bit 18 Base Key thId 6: 31A34 < 80000 or > FFFFF Rekey true

Seed: 50363FA8E9EA517136

Bit 20 CPU Base Key thId 6: BF3E0
cp: cannot create regular file '../drive/MyDrive/Result.txt': No such file or directory


  Addr :1HsMJxNiV7TLxmoF6uJNkydxPFDog4NQum
  Check:1HsMJxNiV7TLxmoF6uJNkydxPFDog4NQum

!!! Result.txt Found key: D2C55
!!! Result.txt Found key: D2C55
!!! Result.txt Found key: D2C55
!!! Result.txt Found key: D2C55
!!! Result.txt Found key: D2C55


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?
With the -r 1 option you can select the fastest one.
If we get lucky.  Grin


Yep...If we get lucky that the same seed works on any puzzle above 65 Grin


Start at 20000... (first 66 bit key) and go sequentially, no random generator needed.

Code:
from tqdm import tqdm
import secp256k1 as ice

# Define the start and end
start = 0x20000000000000000
end = 0x3ffffffffffffffff

# Define the chunk size
chunk_size = 10_000_000

# Initialize the current start and end values
current_start = start
current_end = start + chunk_size

# Initialize the chunk number
chunk_number = 1

while current_start < end:
    current_end = min(current_end, end)
    
    # Create a tqdm progress bar for the current chunk
    with tqdm(total=current_end - current_start, desc=f'Chunk {chunk_number} end {current_end}') as pbar:
        for x in range(current_start, current_end):
            h160 = ice.privatekey_to_h160(2, True, x)
            if bytes.fromhex('20d45a6a762535700ce9e0b216e31994335db8a5') in h160:
                with open("KEYFOUNDKEYFOUND.txt", "a") as f:
                    f.write(str(x) + "-" + (h160.hex()) + "\n")
            pbar.update(1)
    
    # Update the current_start and current_end for the next chunk
    current_start = current_end
    current_end += chunk_size
    chunk_number += 1

Chunk 1 end  36893488147429103232:  22%|█████████████                                               | 2173663/10000000 [00:32<01:58, 65952.81it/s]

About 2 minutes for 10 million hashes. Single core.
 
These are all games for small children, no matter how you turn the ball, the result is small..  Grin

member
Activity: 93
Merit: 16

Thanks. Btw...We don't need such a long seed lenght - even 9 gets the job done.

Code:
 // Seed
  if (seed.length() == 0) {
    // Default seed
    seed = Timer::getSeed(9);
  }

  if (paranoiacSeed) {
    seed += Timer::getSeed(9);
  }

 Wink
You changed the wrong seed.
New Seed begins with a capital letter  Grin
Code:

  //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!  Grin Previously, the old one was just for starters. Next is the code startKey.SetInt32(0)
member
Activity: 462
Merit: 24
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.  Grin

I'm still unable to understand the process, what does it mean selecting the fastest one? Ok, let me get this straight, you are generating what, private keys from a seed? I wanna know how is it possible to generate 1 key from 2 different seeds, this should be impossible unless you are not using random, or you have just changed the key generator, but still doesn't explain how these 2 seeds generated the same private key:
Code:
45730c0cca52f09ac21b00e4ada360e9709152473494e91dfd74b6e11938bf30
b6d88248ed9fa96f42684121433dcaceb655bf37e0b65c007e58d0ad59adecbf

ELI5, please.

The one in the file is the fastest. But there is something else here. This script can be modified to search for a seed - you give it a WIF as input and it rotates all the seeds to hit the fastest one.
copper member
Activity: 1330
Merit: 899
🖤😏
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.  Grin

I'm still unable to understand the process, what does it mean selecting the fastest one? Ok, let me get this straight, you are generating what, private keys from a seed? I wanna know how is it possible to generate 1 key from 2 different seeds, this should be impossible unless you are not using random, or you have just changed the key generator, but still doesn't explain how these 2 seeds generated the same private key:
Code:
45730c0cca52f09ac21b00e4ada360e9709152473494e91dfd74b6e11938bf30
b6d88248ed9fa96f42684121433dcaceb655bf37e0b65c007e58d0ad59adecbf

ELI5, please.
member
Activity: 462
Merit: 24

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.
Code:
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
Code:
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  Grin

Thanks. Btw...We don't need such a long seed lenght - even 9 gets the job done.

Code:
  // Seed
  if (seed.length() == 0) {
    // Default seed
    seed = Timer::getSeed(9);
  }

  if (paranoiacSeed) {
    seed += Timer::getSeed(9);
  }

 Wink
member
Activity: 93
Merit: 16
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.
full member
Activity: 431
Merit: 105
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.  Grin

hi there,

could you make the github hold your different exe files, so we dont have to compile to test all these mods,
i could compile but am a tad late for sleeping i guess. and is this what demining mentiones just wondering

/* 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.
full member
Activity: 1162
Merit: 237
Shooters Shoot...
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.  Grin

You should probably explain what you have in code above. You have 2 different seeds and you say saved to result.txt file. So I can see Diagran’s point.

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.
member
Activity: 93
Merit: 16
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.  Grin
copper member
Activity: 1330
Merit: 899
🖤😏
Should add seed to be written in Results.txt
Code:
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 Grin
Experiment with the least significant bits up to 2^30, which seed is more suitable in terms of solution speed. I like your ideas  Smiley
Added new code to mods on Github. Saving Seed to the Result.txt file.
Then run with the -s option
Code:
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.
file Result.txt
Code:
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  Grin
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?
member
Activity: 93
Merit: 16
Should add seed to be written in Results.txt
Code:
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 Grin
Experiment with the least significant bits up to 2^30, which seed is more suitable in terms of solution speed. I like your ideas  Smiley
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.
Code:
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
Code:
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  Grin
full member
Activity: 1162
Merit: 237
Shooters Shoot...
Because it was a community involved quest; to find the fastest python code to gen and write to a file, 1 million addresses.
Not everything is about the puzzles/challenges.

One could say what is the point of providing a bunch of info on add sub div without concrete examples, from start to finish with result, but some do it anyway.
I know it was a "community challenge", I was wondering if it has any significance to nomachine's code when you said 1M address.
Also do you remember few month back when I could find public keys similar to #125 key? Well I will tell you this but it's not going to help you or anyone else.

Here is a new angle to work with subtraction only, try to subtract #130 from end range to get this :
Code:
0308360beeb0177961b04eccc33decdf63e23d205abc8ef6355d659d1313459ba7
Now if you just subtract 1 from it:
Code:
026a0747b3229f32ce2f0f7bd77a7bd306f6c95d27e7c5bee22a417938d9988605
Now if you add it to #130, you will have :
Code:
03e067911ebf6bacf87a8088ab9344c95843aed80b070eed09f9d947c98dfc0249
00000000000000000000000000000003ffffffffffffffffffffffffffffffff
Now if you subtract the above instead of 1, you get this:
Code:
035dee726b0fe623224fa1f4d79af66a9a1829213ec675875c619266a5f184e7d1
Once again, if you add the above key to #130, you won't get 1,  instead you are actually adding -1 of #130 to #130, you can confirm that by subtracting it from #130.

Ok, why did we get a different result in our first addition? Because we just subtracted 1 from our offset the first time, so no -n result, but when we subtracted a larger key than our offset, the second addition should have given us 1, but why it added -1 of #130 to #130? Because I knew which key was greater than the other, but if you subtract the larger key > 3fffff..... from our offset, the second addition would have resulted in G.

I don't know why I'm explaining modular effect here, this is useless, unless you know a few tricks.


Again, it is hard to follow your work. "Now if you subtract the above instead of 1, you get this:" this is confusing. Just put in code each step you are doing.

Also, the #130 end range is 3ffffffffffffffffffffffffffffffff, and not 400000000000000000000000000000000.

It's really hard following your steps. And I really try lol. Not expecting your steps will teach me something new, but to at least say, yep, his work was correct.

Example:
Code:
Take pub x that is the pub of priv key y
subtract or add 0xf or 16 from it and you get
pub z
etc
etc

[moderator's note: consecutive posts merged]
member
Activity: 462
Merit: 24
I know it was a "community challenge", I was wondering if it has any significance to nomachine's code when you said 1M address.

It doesn't matter if it's 1, 5 or 10 million.
To find a 66-bit number within 10 days, you would need to check approximately 200 (billion) giga/hashes - addresses per second.  It doesn't matter if it's an even or odd number.  Grin

And here is the reason why someone has to invent a new random generator - or new computing technology in general
Code:
import os, random, time
from contextlib import contextmanager

@contextmanager
def timing(label):
    start_time = time.time()
    try:
        yield
    finally:
        end_time = time.time()
        elapsed_time = end_time - start_time
        print(f"{label} Average Time: {elapsed_time:.8f} seconds")

puzzle = 66
start = 2 ** (puzzle - 1)
end = (2 ** puzzle) - 1

def generate_random():  
    return random.randint(start, end)

with timing("generate_random"):
    random_value = generate_random()
    print(random_value)

72040005465485153674
generate_random Average Time: 0.00002623 seconds

you need random generator with
Average Time:  0.000000000002  seconds

And then all other parts of the script no slower than this. Cry

Just replace the files and rebuild the project.


Code:
 make
mkdir -p obj
cd obj && mkdir -p GPU
cd obj && mkdir -p hash
g++ -m64 -mssse3 -Wno-write-strings -O2 -I. -I/usr/local/cuda-8.0/include -I/usr/local/include -o obj/Base58.o -c Base58.cpp
g++ -m64 -mssse3 -Wno-write-strings -O2 -I. -I/usr/local/cuda-8.0/include -I/usr/local/include -o obj/IntGroup.o -c IntGroup.cpp
g++ -m64 -mssse3 -Wno-write-strings -O2 -I. -I/usr/local/cuda-8.0/include -I/usr/local/include -o obj/main.o -c main.cpp
g++ -m64 -mssse3 -Wno-write-strings -O2 -I. -I/usr/local/cuda-8.0/include -I/usr/local/include -o obj/Random.o -c Random.cpp
Random.cpp: In function ‘void RandAddSeed()’:
Random.cpp:154:5: error: ‘memset’ was not declared in this scope
  154 |     memset(&nCounter, 0, sizeof(nCounter));
      |     ^~~~~~
Random.cpp:27:1: note: ‘memset’ is defined in header ‘’; did you forget to ‘#include ’?
   26 | #include
  +++ |+#include
   27 | //
make: *** [Makefile:70: obj/Random.o] Error 1

You need to #include  in Random.cpp Wink

p.s.

Should add seed to be written in Results.txt
Code:
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 Grin

copper member
Activity: 1330
Merit: 899
🖤😏
Because it was a community involved quest; to find the fastest python code to gen and write to a file, 1 million addresses.
Not everything is about the puzzles/challenges.

One could say what is the point of providing a bunch of info on add sub div without concrete examples, from start to finish with result, but some do it anyway.
I know it was a "community challenge", I was wondering if it has any significance to nomachine's code when you said 1M address.
Also do you remember few month back when I could find public keys similar to #125 key? Well I will tell you this but it's not going to help you or anyone else.

Here is a new angle to work with subtraction only, try to subtract #130 from end range to get this :
Code:
0308360beeb0177961b04eccc33decdf63e23d205abc8ef6355d659d1313459ba7
Now if you just subtract 1 from it:
Code:
026a0747b3229f32ce2f0f7bd77a7bd306f6c95d27e7c5bee22a417938d9988605
Now if you add it to #130, you will have :
Code:
03e067911ebf6bacf87a8088ab9344c95843aed80b070eed09f9d947c98dfc0249
00000000000000000000000000000003ffffffffffffffffffffffffffffffff
Now if you subtract the above instead of 1, you get this:
Code:
035dee726b0fe623224fa1f4d79af66a9a1829213ec675875c619266a5f184e7d1
Once again, if you add the above key to #130, you won't get 1,  instead you are actually adding -1 of #130 to #130, you can confirm that by subtracting it from #130.

Ok, why did we get a different result in our first addition? Because we just subtracted 1 from our offset the first time, so no -n result, but when we subtracted a larger key than our offset, the second addition should have given us 1, but why it added -1 of #130 to #130? Because I knew which key was greater than the other, but if you subtract the larger key > 3fffff..... from our offset, the second addition would have resulted in G.

I don't know why I'm explaining modular effect here, this is useless, unless you know a few tricks.😉
member
Activity: 462
Merit: 24
Damn I could really use 32 Bitcoins. I think the code has something to do with 1337

In coding and programming, "1337" doesn't have any specific technical meaning. It's more of a cultural reference. Grin
jr. member
Activity: 43
Merit: 1
Damn I could really use 32 Bitcoins. I think the code has something to do with 1337
Jump to: