So what's the point of making such scripts ?
They believe that nobody else tried their "original ideas" before.
Topic: Bitcoin puzzle transaction ~32 BTC prize to who solves it - page 142. (Read 230098 times)
They believe that nobody else tried their "original ideas" before.
Still .. what this script is really trying to do ? It just generates random 66bit HEX numbers in hope to hit 66 puzzle ? Or is there something else here ?
Not random. It goes Sequentially. "To kill boredom" script. Like all the other useless scripts here.
But ... with that speed ... it's a complete joke. I can do the same with existing tools on nvidia card much faster. So what's the point of making such scripts ?
Still .. what this script is really trying to do ? It just generates random 66bit HEX numbers in hope to hit 66 puzzle ? Or is there something else here ?
Not random. It goes Sequentially. "To kill boredom" script. Like all the other useless scripts here.
Still .. what this script is really trying to do ? It just generates random 66bit HEX numbers in hope to hit 66 puzzle ? Or is there something else here ?
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'
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
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.
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'
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
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
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'
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 ?
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: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 // 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;
//
}
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);
}
if (seed.length() == 0) {
// Default seed
seed = Timer::getSeed(9);
}
if (paranoiacSeed) {
seed += Timer::getSeed(9);
}
New Seed begins with a capital letter
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
}
Previously, the old one was just for starters.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.
Yep...If we get lucky that the same seed works on any puzzle above 65
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
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..
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);
}
if (seed.length() == 0) {
// Default seed
seed = Timer::getSeed(9);
}
if (paranoiacSeed) {
seed += Timer::getSeed(9);
}
New Seed begins with a capital letter
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
}
Previously, the old one was just for starters. Next is the code startKey.SetInt32(0)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.
Code:
45730c0cca52f09ac21b00e4ada360e9709152473494e91dfd74b6e11938bf30
b6d88248ed9fa96f42684121433dcaceb655bf37e0b65c007e58d0ad59adecbf
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.
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.
Code:
45730c0cca52f09ac21b00e4ada360e9709152473494e91dfd74b6e11938bf30
b6d88248ed9fa96f42684121433dcaceb655bf37e0b65c007e58d0ad59adecbf
b6d88248ed9fa96f42684121433dcaceb655bf37e0b65c007e58d0ad59adecbf
ELI5, please.
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
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 PubAddress: 12jbtzBb54r97TCwW3G1gCFoumpckRAPdY
Priv (WIF): p2pkh:KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M82GSgY8p5EkUe
Priv (HEX): 0xD916CE8
Seed: B6D88248ED9FA96F42684121433DCACEB655BF37E0B65C007E58D0AD59ADECBF
PubAddress: 12jbtzBb54r97TCwW3G1gCFoumpckRAPdY
Priv (WIF): p2pkh:KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M82GSgY8p5EkUe
Priv (HEX): 0xD916CE8
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);
}
if (seed.length() == 0) {
// Default seed
seed = Timer::getSeed(9);
}
if (paranoiacSeed) {
seed += Timer::getSeed(9);
}
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.
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.
#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.
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.
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.
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.
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
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 Code:
fprintf(f, "PubAddress: %s\n", addr.c_str());
fprintf(f, "Seed: %s\n", seed.c_str());
fprintf(f, "Seed: %s\n", seed.c_str());
Something like this. So that we can reproduce the same result
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
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 PubAddress: 12jbtzBb54r97TCwW3G1gCFoumpckRAPdY
Priv (WIF): p2pkh:KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M82GSgY8p5EkUe
Priv (HEX): 0xD916CE8
Seed: B6D88248ED9FA96F42684121433DCACEB655BF37E0B65C007E58D0AD59ADECBF
PubAddress: 12jbtzBb54r97TCwW3G1gCFoumpckRAPdY
Priv (WIF): p2pkh:KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M82GSgY8p5EkUe
Priv (HEX): 0xD916CE8
Should add seed to be written in Results.txt
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 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
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
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
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. 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.
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
Code:
026a0747b3229f32ce2f0f7bd77a7bd306f6c95d27e7c5bee22a417938d9988605
Code:
03e067911ebf6bacf87a8088ab9344c95843aed80b070eed09f9d947c98dfc0249
00000000000000000000000000000003ffffffffffffffffffffffffffffffff
Code:
035dee726b0fe623224fa1f4d79af66a9a1829213ec675875c619266a5f184e7d1
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]
Jump to: