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

Any form of processing that uses less input bits than the output bits (or viceversa) is a (de)compression algorithm. I can claim that we can use a single bit to cover 2**256 public keys. 1 = all keys tried, 0 = not all keys tried, but it's not really a public key database. So when you say you can store 100 M public keys using just 655360 bits (80 kB), maybe there's some fine print over that statement, since not even the most optimal possible data structure (some optimal tree of sorts that uses every bit as a node value, and you walk along the tree to read or return some string of bits) can't store 25.6 billion bits of information using only 700k bits. At least not without critical trade-offs like very lossy/wrong results, or extremely slow operations. What's the use-case?

With pubkey - 5 minutes for bsgs sequental with keyhunt (8 threads, k=128).

address:

13zb1hQbWVsc2S7ZTZnP2G4undNNpdh5so

pubkey:

024ee2be2d4e9f92d2f5a4a03058617dc45befe22938feed5b7a6b7282dd74cbdd

pvk:

000000000000000000000000000000000000000000000002832ed74f2b5e35ee

rawtx:

0100000001b3138da741af259146ca2c4895bac7e0c08147679f88ce3302fb4db0584bf31201000 0006a47304402201d69eb8b038805e8c681d981c27f9d22b6b3c62a0fd14b0e37d904547e5931ae 02204b475fe1ef50f4c9823ba37aa9b4c90dbae59e1a4028a61f838987dfefa9da7b0121024ee2b e2d4e9f92d2f5a4a03058617dc45befe22938feed5b7a6b7282dd74cbddfeffffff01158e662300 0000001600140d835f0298e606c9932183672c3156113aca0b2f00000000

SigScript:

47304402201d69eb8b038805e8c681d981c27f9d22b6b3c62a0fd14b0e37d904547e5931ae02204 b475fe1ef50f4c9823ba37aa9b4c90dbae59e1a4028a61f838987dfefa9da7b0121024ee2be2d4e 9f92d2f5a4a03058617dc45befe22938feed5b7a6b7282dd74cbdd

tx:

This did not go through the Mara pool.  

Yeah that's my bet too    but when was that?


Edit -was found September 10, 2022 so it took just over 2 years (wow, almost to the day)

I bet it was immediately after solving puzzle 64

Does anyone remember when we started 66? Wondering how long it took!

Murphy is always working hard to defeat mankind.

 

Probably Puzzle 67 Start with 7 and 68 with F

Key was 2832ed74f2b5e35ee.


No idea, the prize was send to two different addresses.

my bot was off this week sadly Murphy's law has been fulfilled

private key = 0x000000000000000000000000000000000000000000000002832ed74f2b5e35ee

you find priv ?

Congrats! send a gift to the developers of the tools.

13zb1hQbWVsc2S7ZTZnP2G4undNNpdh5so= 024ee2be2d4e9f92d2f5a4a03058617dc45befe22938feed5b7a6b7282dd74cbdd

Did the bots snatch it? Alberto??

Gratz to the first that the puzzle  66 got confirmed 

fo get key from 2^27 need a

2×2×2×2×2×2×2×2×2×2×2×2×2×2×2×2×2×2×2×2×2×2×2×2×2×2×2 = 134217728 pubkeys. this downgrade pubkey  2^27 to pubkey with privkey 1

same situation with downgrade 2^130 to 2^103 etc


if substract 1 bit, from 2^30 need initial 2^27 pubkeys  to take one of them in result with privkey 1. Because all step generate 50/50 probability  what  will go to - areal or you steal in + area


I think what way of kangaroo or bsgs has no resources for find DLP of lage privkey, and qantum computers is more fare problem for btc securety then neuronetworks. So maybe this DB can help make network with enough mutations for solve problem.

enothe interesting I think what bits in privkeys has a paterns, I thin youse paters can speed up finding privkeys, for ex lets see to privkey 2^100:

https://privatekeys.pw/key/000000000000000000000000000000000000000af55fc59c335c8ec67ed24826


ib bits:

1010111101010101111111000101100111000011001101011100100011101100011001111110110 100100100100000100110


Sequence 1010 appears 6 times
Sequence 0101 appears 6 times
Sequence 1011 appears 6 times
Sequence 0111 appears 6 times
Sequence 1111 appears 8 times
Sequence 1110 appears 6 times
Sequence 1101 appears 5 times
Sequence 1100 appears 7 times
Sequence 1000 appears 5 times
Sequence 0001 appears 5 times
Sequence 0010 appears 6 times
Sequence 0110 appears 7 times
Sequence 1001 appears 8 times
Sequence 0011 appears 7 times
Sequence 0000 appears 3 times
Sequence 0100 appears 6 times

so using sequences is more fast then generate all 2^100


scrypt for get sequences:


def count_sequences(number):
    sequences = {}
    for i in range(len(number) - 3):
        sequence = number[i:i+4] #repace 4 to get sequnces with another lenght
        if sequence in sequences:
            sequences[sequence] += 1
        else:
            sequences[sequence] = 1
    return sequences

number = "1010111101010101111111000101100111000011001101011100100011101100011001111110110 100100100100000100110"
sequences = count_sequences(number)

for sequence, count in sequences.items():
    print(f"Sequence {sequence} appears {count} times")


posible to check puzzle privkey and find what pizzle haz a 38 combinations from 64 total posible combinations with each vombinations lenght 6. Total combinations is a same to brute only then try all cases with 38 combinations, but probkey vill be foumded not after check all cases, but example after half of them ...



another way:

imput privkey

0x2ca447fa844948c661d1e35ada56713d7

for get pubkey of 0x17c93cb4fa4bfbb from input key

need from this sequence

1234567890123456789012345678901234567890123456789012345678901234567890123456789 012345678901234567890123456789012345678901234


remove jast this numbers(put "," between all numbers for batter understanding

91231161189747822734455


you get

1234567804567890234567890234578902345678902345670123456890123569013456789013456 89012567890123678901234


after sunstract all numbers in sequnce from pubkey and divide to each step to 9, you get 
0x17c93cb4fa4bfbb  pubkey in 91231161189747822734455 operations


 
OДИH 91231161189747822734455 23
ДBA 1234567804567890234567890234578902345678902345670123456890123569013456789013456 89012567890123678901234 102
TPИ 1234567890123456789012345678901234567890123456789012345678901234567890123456789 0123456789012345678901234567890123456789012345 125

your DB is real powerful DB !!! Thank you for DB.

with the way the data is stored it does not require a complex decompression system (it is not a compression algorithm) it is a system designed exclusively for searching for public keys, therefore it is handled by the search script as if you put 10 public keys in a text file to give a basic example, as for how many public keys could it store until being affected by the size of the db, well, it will depend on the reading capacity in large files, however in a 1gb file you would have approximately 2,621,400,000,000 pubkeys, you need more gb without losing reading speed, we could adapt a bloom filter .. but this is only an initial version of an idea that can be improved over time.

They say the Crucial T705 NVMe speed is 12/14 GB/s

But you also need a (high-end) motherboard that supports this transfer rate.

I can do 200 million secp256k1 pubkey additions/s, so generate 200 new million pub keys per second, by using 20 CPU cores, each running at 10 Mop/s. Can your DB handle this multi-threaded mode? Even a mature DBMS will have serious issues storing the first batch of results. It would also need a disk that can handle writing at least 32 bytes * 200 M = 6.4 GB/s ~= 50 Gbps, which don't even exist yet AFAIK. So, is it really about how fast secp256k1 can get, or about the limits of your DB?

The speed depends how fast your implementation of Seck256k1, does not require a demanding effort of resources for the writing/reading phase of the DB, which was the big problem of DB in the puzzles.

I would prefer any day choosing to use an as fast as possible database that returns or writes results as immediately as possible, rather than a CPU-hungry tiny database. And all databases are binary... Sounds like you're just compressing some bit-map of ranges, what's the actual worst-case update/query/insert efficiency of your database? This is a problem that already has been solved in much faster and smarter ways, e.g. GZIP, LZMA, deflate, etc.