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

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.

wish you best of luck and happy hunting

My new public key search system is almost ready. I had to reinvent my binary database system because, although the database was lightweight  https://bitcointalksearch.org/topic/lightweight-database-for-brute-force-using-publickeys-32mk-381mbsecp256k1-5475626, I had efficiency issues with binary search. This is now a thing of the past. I have designed a system that stores 100 million public keys in an 80 KB file, yes, what you read 80KB!(in the future it will be smaller) that meets maximum efficiency. We would only be limited by the current speed of Secp256k1 when generating the 100 million or more public keys while creating the database. I am finishing designing the search script after months of being stuck due to personal issues, I am finally back on track.

Too much math going on here.   

Can we Beat the Square Root Bound for ECDLP over Fp2 via Representations?

https://eprint.iacr.org/2019/800.pdf

He's not making a smaller N or a smaller range size, he is using curve symmetry. There is no "fooling" N.

If you are searching for a public key that is originally in a 60 bit range, manual but easy to explain way, take secp256k1 N and subtract 2^59 from it. This is your lower bound / start range. Your upper bound / end range will be 2^60-1. Same size range, but now it is using the curves symmetrical properties.
Now, you can start the 1 tame and 1 wild on the -negative side (lower bound side) and 1 tame and 1 wild on your positive side (upper bound side).

I was make only 1 answer to you.