 Show Posts
|
|
Pages: « 1 2 3 [4] 5 »
|
Someone said that the parity of the target private key does not matter  This has implications for the choice of divisor. If the private key is divisible by divide key without a remainder, then the divisor is correct. PrivKey % DivideKey = 0. But because the target key is not known, the correct divisor can only be random. The same applies to public keys, which also have parity. Example of correct divisors for a test private key: 0x197D95F81F7BA421E829611A8F8BB1204 % 0x15B = 0 [i] NB: 0 DIVKey: 1 Inverse DivideKey: 1
[i] 1 TRUE DIVIDER NB: 4 TestKey: 0x197D95F81F7BA421E829611A8F8BB1204 Divider: 0x2 Result: 0xCBECAFC0FBDD210F414B08D47C5D8902
[i] 2 TRUE DIVIDER NB: 62 TestKey: 0x197D95F81F7BA421E829611A8F8BB1204 Divider: 0x7 Result: 0x3A439FEDFED17728EE15703CB5D194DC
[i] 3 TRUE DIVIDER NB: 126 TestKey: 0x197D95F81F7BA421E829611A8F8BB1204 Divider: 0x1 Result: 0x197D95F81F7BA421E829611A8F8BB1204
[i] NB: 200 DIVKey: 10C Inverse DivideKey: 2DD9CA81E9131ABF0B7672A07A44C6AF8899965ECF27C0FF3D1A3724AED80BB
[i] 4 TRUE DIVIDER NB: 329 TestKey: 0x197D95F81F7BA421E829611A8F8BB1204 Divider: 0x2 Result: 0xCBECAFC0FBDD210F414B08D47C5D8902
[i] NB: 400 DIVKey: 23C Inverse DivideKey: 51E6EFE35B4CFAA11E6EFE35B4CFAA117EDBBF8316F5AB35212C7A71F936F3C2
[i] 5 TRUE DIVIDER NB: 418 TestKey: 0x197D95F81F7BA421E829611A8F8BB1204 Divider: 0x15B Result: 0x12CE43D9BA45157E164076DAC9CF14C
[i] 6 TRUE DIVIDER NB: 585 TestKey: 0x197D95F81F7BA421E829611A8F8BB1204 Divider: 0x4 Result: 0x65F657E07DEE9087A0A5846A3E2EC481
[i] NB: 600 DIVKey: 23E Inverse DivideKey: 4039164CB5F71484039164CB5F71483FE77978885DECC19E99607B9F4FE2CBB
[i] NB: 800 DIVKey: 1C0 Inverse DivideKey: 6D24924924924924924924924924924899E043E4A2BAF6997935B04F767BB3D2
[i] 7 TRUE DIVIDER NB: 809 TestKey: 0x197D95F81F7BA421E829611A8F8BB1204 Divider: 0x373 Result: 0x763E70ED25521F5892DEADDA978CEC
[i] 8 TRUE DIVIDER NB: 834 TestKey: 0x197D95F81F7BA421E829611A8F8BB1204 Divider: 0x1 Result: 0x197D95F81F7BA421E829611A8F8BB1204
[i] NB: 1000 DIVKey: DE Inverse DivideKey: B9A85C40939A85C40939A85C40939A84D81BA4D0CFD743C5DAAE799D7904C09F
[i] 9 TRUE DIVIDER NB: 1062 TestKey: 0x197D95F81F7BA421E829611A8F8BB1204 Divider: 0x15B Result: 0x12CE43D9BA45157E164076DAC9CF14C
[i] 10 TRUE DIVIDER NB: 1072 TestKey: 0x197D95F81F7BA421E829611A8F8BB1204 Divider: 0x2 Result: 0xCBECAFC0FBDD210F414B08D47C5D8902
[i] 11 TRUE DIVIDER NB: 1127 TestKey: 0x197D95F81F7BA421E829611A8F8BB1204 Divider: 0x15B Result: 0x12CE43D9BA45157E164076DAC9CF14C
[i] 12 TRUE DIVIDER NB: 1169 TestKey: 0x197D95F81F7BA421E829611A8F8BB1204 Divider: 0x2 Result: 0xCBECAFC0FBDD210F414B08D47C5D8902
[i] NB: 1200 DIVKey: 14C Inverse DivideKey: 80C565C87B5F9D4D1BC2503159721ED743AFDC9C2231A3E05E2CE713F071A6FE
[i] 13 TRUE DIVIDER NB: 1337 TestKey: 0x197D95F81F7BA421E829611A8F8BB1204 Divider: 0x1C Result: 0xE90E7FB7FB45DCA3B855C0F2D746537
[i] NB: 1400 DIVKey: 2C0 Inverse DivideKey: A28BA2E8BA2E8BA2E8BA2E8BA2E8BA2DBD141E710462D73192E306F16890FE86
[i] 14 TRUE DIVIDER NB: 1477 TestKey: 0x197D95F81F7BA421E829611A8F8BB1204 Divider: 0x2 Result: 0xCBECAFC0FBDD210F414B08D47C5D8902
[i] 15 TRUE DIVIDER NB: 1542 TestKey: 0x197D95F81F7BA421E829611A8F8BB1204 Divider: 0x4 Result: 0x65F657E07DEE9087A0A5846A3E2EC481
[i] 16 TRUE DIVIDER NB: 1578 TestKey: 0x197D95F81F7BA421E829611A8F8BB1204 Divider: 0x373 Result: 0x763E70ED25521F5892DEADDA978CEC
[i] NB: 1600 DIVKey: 1EE Inverse DivideKey: 79C8084A9F9C8084A9F9C8084A9F9C7FE9E86E4447FBAEAF98EB545CE5A3A7DA
[i] 17 TRUE DIVIDER NB: 1619 TestKey: 0x197D95F81F7BA421E829611A8F8BB1204 Divider: 0x2B6 Result: 0x96721ECDD228ABF0B203B6D64E78A6
[i] NB: 1800 DIVKey: 346 Inverse DivideKey: 50F46433527B6AEBD67415FEC72DD2C938973869F12AD2BF30BEDBE9EEBFE597
[i] 18 TRUE DIVIDER NB: 1880 TestKey: 0x197D95F81F7BA421E829611A8F8BB1204 Divider: 0x1C Result: 0xE90E7FB7FB45DCA3B855C0F2D746537
[i] NB: 2000 DIVKey: 4A Inverse DivideKey: 2CF914C1BACF914C1BACF914C1BACF9112F534A510F48ADA1066AFBECAA1BF5B
[i] Data Saved in file DivideKeys.txt
It is impossible to find the correct divisor for a public key; you need a private key. |
|
|
|
At the Puzzle creator tattooed on the upper arm.  I don't see any other solution than that the input is random. Tattoo with QR code. Yes .
It doesn't matter what our target is, even or odd you just need to correctly guess the last 2 hex characters and then you can use the script I posted above to divide your key by 1024, but first you'd need to subtract n/4 from the result on 1024 - index.
Try it yourself and you will see, even if we guess the last 2 chars incorrectly, there is a way to again calculate p/1024 no matter what. God willing I should be able to figure that out, it's complicated I know but once it's solved you realize how easy it was.
Spent a lot of time, but I haven't gotten the correct result. |
|
|
|
I still don't understand what you need to do to find the private key after find the key subtraction result, if I understand it maybe I could write a CUDA version for it.
It is impossible to determine whether a point on a curve is even or odd - without a known private key. Therefore, factoring a known private key into factors is a waste of time. |
|
|
|
if we want to trim the high bytes of the derived key with zeros, can we do so by copying only the lower bytes of the key to the BIGNUM ?
Yes. Only he edited the high bits. Or maybe bytes  I just replaced the high byte with 0x2. Why divide modulo Range? Modulo the Order is probably correct, it gives a different result. And then cut off the 32-bit string. I found an error again unsigned char derivedKey[64]; // SHA-512 produces a 64-byte key
if (PKCS5_PBKDF2_HMAC((const char*)BN_bn2hex(minKey), BN_num_bytes(minKey), salt, sizeof(salt), 0, EVP_sha512(), sizeof(derivedKey), derivedKey) != 1) {
// Handle error
return nullptr;
}
****************************************************************************************
int PKCS5_PBKDF2_HMAC(const char *pass, int passlen,
const unsigned char *salt, int saltlen, int iter,
const EVP_MD *digest,
int keylen, unsigned char *out);
****************************************************************************************
pass the seed - Input data passlen salt = "Bitcoin seed"; // Salt is always constant ! iter = 1 // Didn't look at the code? 0 gives 1 intervention? or 2048 intervention? // in VanitySearch version function 0 gives 1 iteration. keylen = 64 ------------------------------------------------------------------------------------------- Where is the Input data  |
|
|
|
I made a new key generator. Tested the HMAC-SHA512 function, the data output is correct. Added a split of the 512 bit key into 2 keys - respectively 256 bits each. It may not be necessary to add anything more, all the initial data is not known... // Get Keys from SEED
void VanitySearch::getKeysFromRandomSeed(int nbitL, int nbitU, bool master, int nbThread, Int *keys) {
// Generate a seed byte sequence S of a chosen length (between 128 and 512 bits; 256 bits is advised) from a (P)RNG.
// Calculate I = HMAC-SHA512(Key = "Bitcoin seed", Data = S)
// Split I into two 32-byte sequences, IL and IR.
// Use parse256(IL) as master secret key, and IR as master chain code.
// Variables
Int IL;// IL as master secret key
Int IR;// IR as master chain code
Int pKey;
Int sKey;
// Master key generation
for (int i = 0; i < nbThread; i++) {
newSeed:
string seed = Timer::getSeed(32);// Used the random seed ???
// test seed
//seed = "bla bla bla";// Mnemonic code words
string salt = "Bitcoin seed";// = "VanitySearch";
unsigned char hseed[64];
pbkdf2_hmac_sha512(hseed, 64, (const uint8_t *)seed.c_str(), seed.length(),
(const uint8_t *)salt.c_str(), salt.length(),
hmac_sha512_nb_round);// 1024 Electrum ?
//2048);// 2048 rounds of hashing required by the BIP 39 Standard ???
// Reverse bytes (not use sha256)
unsigned char hseed_r[64];
int b = 0;
for (b = 0; b < 64; b++) hseed_r[63 - b] = hseed[b];
// Split I into two 32-byte sequences, IL and IR.
// Use parse256(IL) as master secret key, and IR as master chain code.
// Split IL and IR
unsigned long long *vTmp_IL = (unsigned long long *)&hseed_r[32];// IL as master secret key
unsigned long long *vTmp_IR = (unsigned long long *)&hseed_r;// IR as master chain code
IL.bits64[0] = vTmp_IL[0];
IL.bits64[1] = vTmp_IL[1];
IL.bits64[2] = vTmp_IL[2];
IL.bits64[3] = vTmp_IL[3];
IL.bits64[4] = 0;
//
IR.bits64[0] = vTmp_IR[0];
IR.bits64[1] = vTmp_IR[1];
IR.bits64[2] = vTmp_IR[2];
IR.bits64[3] = vTmp_IR[3];
IR.bits64[4] = 0;
// end Split
// debug printf
printf("\n[i] Nb: %d Key IL: %s ", i, IL.GetBase16().c_str());
printf("\n[i] Nb: %d Key IR: %s ", i, IR.GetBase16().c_str());
// Set Keys 256 bits
pKey.SetInt32(0);
sKey.SetInt32(0);
// Switch IL or IR
if (master) {
pKey.Set(&IL);// IL as master secret key
} else {
pKey.Set(&IR);// IR as master chain code
}
// Set Key in ranges nbitL and nbitU
uint32_t nb = nbitU / 32;
uint32_t leftBit = nbitU % 32;
uint32_t mask = 1;
mask = (mask << leftBit) - 1;
uint32_t j = 0;
for(j = 0; j < nb; j++)
sKey.bits[j] = pKey.bits[j];
sKey.bits[j] = pKey.bits[j] & mask;
//sha256(hseed, 64, (unsigned char *)sKey.bits64);// No used this function
// Trim with zeros ???
// We do not know how the high byte of the key were edited. 32 BTC Puzzle.
if (nbitU == 66) {
//printf("\n[i] Nb: %d sKey: %s ", i, sKey.GetBase16().c_str());
//sKey.SetByte(8, 0x02);// The high byte is 0x02
sKey.SetByte(8, (unsigned char)KEY66_HIGH_BYTE);// The high byte is 0x03
//printf("\n[i] Nb: %d sKey: %s ", i, sKey.GetBase16().c_str());
}
// Check length
int len = sKey.GetBitLength();
if (len < nbitL) goto newSeed;
keys[i].Set(&sKey);// Set Keys
// Hi ;-) The END ???
}
}
VanitySearch cannot divide a 512-bit number modulo the Order (only 320 bits). For this need BigNum from the OpenSSL library. Here again need OpenSSL, no matter what  |
|
|
|
As the creator said, you need to trim the high bytes of the key with zeros!
I think it's obvious that he has his own custom deterministic wallet. Based on an existing one or completely new one from scratch.
That said, I'm not sure it can sign a message with that tool. Maybe. And it’s not even necessary, just add your own salt, and that will be enough - going over SEED will be useless. string seed = Timer::getSeed(32);
//seed = "bla bla bla";// Mnemonic code words
string salt = "Bitcoin seed";// = "VanitySearch";
unsigned char hseed[64];
pbkdf2_hmac_sha512(hseed, 64, (const uint8_t *)seed.c_str(), seed.length(),
(const uint8_t *)salt.c_str(), salt.length(),
//2048);// 2048 rounds of hashing required by the BIP 39 Standard ???
//2048);// Used 2048 rounds ???
//0);// Used 0 rounds !!!
1024);// Electrum ?
|
|
|
|
seed = random.getrandbits(128)
seed_value = int(seed)
random.seed(seed_value)
seed = str(seed_value)
It's not even close to 128. The closest I've come up with 8 to 2 ** 65 30568377238562584866, b'\xc9\xd9\x1d\xbc\x16\x9d\xdb\x86' import random
puzzle = 65
lower_range_limit = 2 ** (puzzle - 1)
upper_range_limit = (2 ** puzzle) - 1
owner_salt = b'\xc9\xd9\x1d\xbc\x16\x9d\xdb\x86'
random.seed(owner_salt)
dec = random.randint(lower_range_limit, upper_range_limit)
print(f"{dec}, {owner_salt}") but even so a part is missing to get a 100% accurate result. it seems most likely that pbkdf2_hmac was used hashlib.pbkdf2_hmac('sha512', os.urandom(8 ), b'', iterations=1024)[:32] some combination like this. In that code, the 512-bit key is normalized by division modulo % CURVE_ORDER from_arbitrary_size_secret() def normalize_secret_bytes(cls, privkey_bytes: bytes) -> bytes:
scalar = string_to_number(privkey_bytes) % CURVE_ORDER
if scalar == 0:
raise Exception('invalid EC private key scalar: zero')
privkey_32bytes = number_to_string(scalar, CURVE_ORDER)
return privkey_32bytes
As the creator said, you need to trim the high bytes of the key with zeros! |
|
|
|
Thanks for the advice. I'll take a look at this code. I just installed 2048 interactions and the keys began to be generated for a very long time. |
|
|
|
Creator use master keys or child keys? BIP-32 or BIP-39 format? Who can know?
If I can say anything it'd be for the author of this puzzle to bless me beyond my own imagination I have tried my best but I am still not going to give up either. you can search or do a lookup of my wallet address. I have definitely invested over $30k in the puzzle 66 alone throughout the whole random scan and my wallet address is 1h7EsfXpgCLftpU4vucjkCbX1Wktop8GM, you can do your search from the private key scanner or 66 bits puzzle I spend so much resources there but no luck I am running my search lowkey now but I am almost being drained but still not giving up A blessing is nothing imaginable or unimaginable but nothing is impossible for God to do. I just pray for the ability to be able to keep up as it is so much fun It is likely that he used a BIP-39 wallet. Because BIP 0039 was created on 2013-09-10, and it is more durable. Uses 2048 rounds of HMAC-SHA512 hashing from SEED. This means that an attack on SEED is not possible. A short phrase of unknown length out of a possible 2048 words. Maybe she's not on the BIP-39 wirdlist. We will never know. I'm currently making a random seed code using the HMAC-SHA512 function. That's why I asked I've already split a 512-bit key into 2 256-bit keys... For now I'll continue this... |
|
|
|
|
Сreator use master keys or child keys? BIP-32 or BIP-39 format? Who can know?
|
|
|
|
why not ? Without predictable SEED there will be more chances |
|
|
|
Yo Nomachine,
nice catch, where's our current puzzle 66 in there,
thanks works like a charm.
The same thing, but only after 100 years. I think this script is useless. ====================================
linuxtime: 4573737217
Puzzle 1
Private Key : 0x1
Timestamp: 2114-12-08 21:33:37
====================================
linuxtime: 4576602332
Puzzle 2
Private Key : 0x3
Timestamp: 2115-01-11 01:25:32
====================================
linuxtime: 4576602332
Puzzle 3
Private Key : 0x7
Timestamp: 2115-01-11 01:25:32
====================================
linuxtime: 4571281403
Puzzle 4
Private Key : 0x8
Timestamp: 2114-11-10 11:23:23
====================================
linuxtime: 4575384117
Puzzle 5
Private Key : 0x15
Timestamp: 2114-12-27 23:01:57
====================================
linuxtime: 4576538378
Puzzle 6
Private Key : 0x31
Timestamp: 2115-01-10 07:39:38
====================================
linuxtime: 4571025590
Puzzle 7
Private Key : 0x4c
Timestamp: 2114-11-07 12:19:50
====================================
linuxtime: 4570872102
Puzzle 10
Private Key : 0x202
Timestamp: 2114-11-05 17:41:42
====================================
linuxtime: 4576802823
Puzzle 8
Private Key : 0xe0
Timestamp: 2115-01-13 09:07:03
====================================
linuxtime: 4574581413
Puzzle 13
Private Key : 0x1460
Timestamp: 2114-12-18 16:03:33
====================================
linuxtime: 4571991458
Puzzle 12
Private Key : 0xa7b
Timestamp: 2114-11-18 16:37:38
====================================
linuxtime: 4575374435
Puzzle 9
Private Key : 0x1d3
Timestamp: 2114-12-27 20:20:35
====================================
linuxtime: 4570872160
Puzzle 11
Private Key : 0x483
Timestamp: 2114-11-05 17:42:40
====================================
linuxtime: 4575758239
Puzzle 15
Private Key : 0x68f3
Timestamp: 2115-01-01 06:57:19
====================================
linuxtime: 4572100404
Puzzle 14
Private Key : 0x2930
Timestamp: 2114-11-19 22:53:24
====================================
linuxtime: 4573632515
Puzzle 20
Private Key : 0xd2c55
Timestamp: 2114-12-07 16:28:35
====================================
|
|
|
|
Alek, for the win. Long time no hear/see.
Glad you’ve made it back.
What does your new program do exactly? The VanitySearch one.
Myself, no one wanted to combine forces to attack 130, so I’ve just been tinkering on different things.
Nothing new, not any closer than I was months ago.
Thanks! This is a fork, it’s not mine programm, the program is optimized for a puzzle, but I removed everything unnecessary from the code and introduced a new random generator - no predictable random, as it was before. |
|
|
|
///
Int PrivateKey = minKey; // THE ERROR First it is announced, then it is established. Int PrivateKey; PrivateKey.Set(&minKey); Yes, you can do it in different ways.... |
|
|
|
Now will start on a small range. Let's say // Configuration for the Puzzle // Set minKeyBN and maxKeyBN using the provided base 10 values BN_dec2bn(&minKeyBN, "30568377312063203855"); BN_dec2bn(&maxKeyBN, "30568377312065203855"); std::string targetAddress = "18ZMbwUFLMHoZBbfpCjUJQTCMCbktshgpe"; This is how looks when hits - Fri Sep 29 18:01:54 2023
- 18ZMbwUFLMHoZBbfpCjUJQTCMCbktshgpe
- PUZZLE SOLVED: 2023-09-29 18:02:59
- WIF: KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZM21gaY8WN2CdwnTG57
You can also stretch the random key space and search for 66 and 67 at once. Something like this: Bit 66 CPU Base Key thId 0: 2070B59CFFB6E8A6C
[i] Random Keys - Low Keys Space 2^(67-2) 0x20000000000000000
Bit 67 CPU Base Key thId 1: 5F69D80358D3D5461
[0.83 Mkey/s][GPU 0.00 Mkey/s][Total 2^29.06][Prob 0.0%][50% in 3.88754e+34y][Found 0] [i] Random Keys - Low Keys Space 2^(67-2) 0x20000000000000000
Bit 66 CPU Base Key thId 1: 2E3C205D5E1AED2B1
[i] Random Keys - Low Keys Space 2^(67-2) 0x20000000000000000
Bit 66 CPU Base Key thId 0: 310A2ED5261C2A060
[0.80 Mkey/s][GPU 0.00 Mkey/s][Total 2^29.18][Prob 0.0%][50% in 4.03042e+34y][Found 0] [i] Random Keys - Low Keys Space 2^(67-2) 0x20000000000000000
Bit 66 CPU Base Key thId 0: 218520C965083E2EC
[i] Random Keys - Low Keys Space 2^(67-2) 0x20000000000000000
Bit 67 CPU Base Key thId 1: 5BCD840005DB9C7A0
[0.79 Mkey/s][GPU 0.00 Mkey/s][Total 2^29.29][Prob 0.0%][50% in 4.04933e+34y][Found 0] [i] Random Keys - Low Keys Space 2^(67-2) 0x20000000000000000
Bit 67 CPU Base Key thId 1: 670DE68F544FE981A
[i] Random Keys - Low Keys Space 2^(67-2) 0x20000000000000000
Bit 67 CPU Base Key thId 0: 52D16C4062A5F03A4
[0.82 Mkey/s][GPU 0.00 Mkey/s][Total 2^29.35][Prob 0.0%][50% in 3.89443e+34y][Found 0]
|
|
|
|
Are you trying to crack sha256 and hash160 simultaneously?
ecc has no relationship with these hashes, if your method, whatever it is, returns two results that partially agree, it is only a coincidence.
He will continue this outrage, he still thinks that there is a direct relationship between a certain range of keys and the received addresses, which partially coincide with the target one. He doesn't know anything. |
|
|
|
Look closely, I am working with artistic binary, not with base58, Ripemd160, decimal, or hexadecimal. and just print output in any format, If you have any output result even in any format, please show us. 100% of people are trying randomly even in 130 also, and I am also trying randomly, but with some logic. You are a master of mathematics, so you can solve 130 directly even with your mobile. All the best!
Then you should go to an art school to teach |
|
|
|
////
Do you know how any linear function differs from the sha256 and Ripemd160 functions? All your calculations make no sense, because... The output value of sha256 hash and Ripemd160 hash changes completely even if 1 byte of the input data changes. Points on a curve can be counted - these are linear calculations (addition and modulo division). And everything else that is obtained after hashing with the sha256 and Ripemd160 functions becomes non-linear data. Please clarify this!!!!!!!! The entire topic was filled with these useless calculations. This can be regarded as spam, because... you have many similar messages. |
|
|
|
I have to admit that Open SSL is very good.  To have a good probability of finding, you need a good randomness of the search. Sounds logical . I have not studied probability theory. Previously, the program included the Mersenne Twister algorithm. The Mersenne Twister is a general-purpose pseudorandom number generator (PRNG) developed in 1997 by Makoto Matsumoto. This algorithm is predictable, and external events are seconds of time and a hashed SEED from the command line. OpenSSL is certainly better. |
|
|
|
|
