Bitcoin puzzle transaction ~32 BTC prize to who solves it

[WanderingPhilospher]

Gratz to the first that the puzzle  66 got confirmed  

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

13zb1hQbWVsc2S7ZTZnP2G4undNNpdh5so= 024ee2be2d4e9f92d2f5a4a03058617dc45befe22938feed5b7a6b7282dd74cbdd

private key = 0x000000000000000000000000000000000000000000000002832ed74f2b5e35ee

[albert0bsd]

Key was 2832ed74f2b5e35ee.

Did the bots snatch it? Alberto??

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

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

[mcdouglasx]

Gratz to the first that the puzzle  66 got confirmed  

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

13zb1hQbWVsc2S7ZTZnP2G4undNNpdh5so= 024ee2be2d4e9f92d2f5a4a03058617dc45befe22938feed5b7a6b7282dd74cbdd

private key = 0x000000000000000000000000000000000000000000000002832ed74f2b5e35ee

Probably Puzzle 67 Start with 7 and 68 with F

[Woz2000]

Murphy is always working hard to defeat mankind.

 

Key was 2832ed74f2b5e35ee.

Did the bots snatch it? Alberto??

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

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

[Woz2000]

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

[albert0bsd]

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

I bet it was immediately after solving puzzle 64

[Woz2000]

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)

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

I bet it was immediately after solving puzzle 64

[nomachine]

This did not go through the Mara pool.  

[pbies]

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:

Code:

{
    "txid": "57a88f47e4c047740b782a5562fca143ce85de0373cbff3a7d406e9ae7fc2f5f",
    "hash": "57a88f47e4c047740b782a5562fca143ce85de0373cbff3a7d406e9ae7fc2f5f",
    "version": 1,
    "size": 188,
    "vsize": 188,
    "weight": 752,
    "locktime": 0,
    "vin": [
        {
            "txid": "12f34b58b04dfb0233ce889f674781c0e0c7ba95482cca469125af41a78d13b3",
            "vout": 1,
            "scriptSig": {
                "asm": "304402201d69eb8b038805e8c681d981c27f9d22b6b3c62a0fd14b0e37d904547e5931ae02204b475fe1ef50f4c9823ba37aa9b4c90dbae59e1a4028a61f838987dfefa9da7b[ALL] 024ee2be2d4e9f92d2f5a4a03058617dc45befe22938feed5b7a6b7282dd74cbdd",
                "hex": "47304402201d69eb8b038805e8c681d981c27f9d22b6b3c62a0fd14b0e37d904547e5931ae02204b475fe1ef50f4c9823ba37aa9b4c90dbae59e1a4028a61f838987dfefa9da7b0121024ee2be2d4e9f92d2f5a4a03058617dc45befe22938feed5b7a6b7282dd74cbdd"
            },
            "sequence": 4294967294
        }
    ],
    "vout": [
        {
            "value": 5.93923605,
            "n": 0,
            "scriptPubKey": {
                "asm": "0 0d835f0298e606c9932183672c3156113aca0b2f",
                "desc": "addr(bc1qpkp47q5cucrvnyepsdnjcv2kzyav5ze0ta7n67)#772ggssc",
                "hex": "00140d835f0298e606c9932183672c3156113aca0b2f",
                "address": "bc1qpkp47q5cucrvnyepsdnjcv2kzyav5ze0ta7n67",
                "type": "witness_v0_keyhash"
            }
        }
    ]
}

[kTimesG]

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.

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?

[WanderingPhilospher]

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.

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?

Go look at the post he linked.

Pretty cool what he did to create a small DB. The problem was, the slow search speed, for actually looking for "match(es)". I am hoping that is what was fixed.

I was able to store something like 40 billion pub keys, eating up only (can't remember exact) but somewhere between 2-7 GB of storage.

If pub ends with negative number, store as 0, if positive, store as 1.

I was able to speed up his search by a factor of 10x, but it was still too slow to make way in a 130 bit range.

[mcdouglasx]

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.

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?

What happens is that you take the idea to your own needs, and you get confused because you are looking for a use to something that you do not know how it is used, in the context of my scripts is that I give the data, now that the same DB does not work For Kangaroo or Bsgs maybe if not, but that does not destroy the main idea.

[albert0bsd]

Yes i remember that database, the idea is cool, but as we me talk before the problem is the search speed, I think in different workarounds over that idea but none of them was efficient, I am going to think on it again, maybe some mix between a custom bloom-filter and some bit rotation can make it work, but I don't know final speed until I test it.

And if that database works, it can't be used with kangaroo, but it can be used with BSGS. If anyone wants to work with that idea please let me know.

By the way. I think that the puzzle66 Original transaction was actually replaced by someone, look:

There is a older transaction with less fee: 8c8ec6b3511c62500ea9b3a1c30ca937e15d251b55d30290a2a6da2f1124f3fb



It has only 5.22 sat/vB and all the inputs the destination address was: 1Jvv4yWkE9MhbuwGUoqFYzDjRVQHaLWuJd


   
But it was replaced 45 seconds after with the Mined TX: 57a88f47e4c047740b782a5562fca143ce85de0373cbff3a7d406e9ae7fc2f5f



That TX is 406 sat/vB and only has one input to a different address: bc1qpkp47q5cucrvnyepsdnjcv2kzyav5ze0ta7n67

all other inputs were send One block after, this look really oddly looks like bot misconfigured but anyway, that already happened and we only can speculate with it

[citb0in]

The forks were also plundered BCH was emptied a few minutes later.

Congrats to the winner!!!! 

[WanderingPhilospher]

Yes i remember that database, the idea is cool, but as we me talk before the problem is the search speed, I think in different workarounds over that idea but none of them was efficient, I am going to think on it again, maybe some mix between a custom bloom-filter and some bit rotation can make it work, but I don't know final speed until I test it.

And if that database works, it can't be used with kangaroo, but it can be used with BSGS. If anyone wants to work with that idea please let me know.

By the way. I think that the puzzle66 Original transaction was actually replaced by someone, look:

There is a older transaction with less fee: 8c8ec6b3511c62500ea9b3a1c30ca937e15d251b55d30290a2a6da2f1124f3fb



It has only 5.22 sat/vB and all the inputs the destination address was: 1Jvv4yWkE9MhbuwGUoqFYzDjRVQHaLWuJd


   
But it was replaced 45 seconds after with the Mined TX: 57a88f47e4c047740b782a5562fca143ce85de0373cbff3a7d406e9ae7fc2f5f



That TX is 406 sat/vB and only has one input to a different address: bc1qpkp47q5cucrvnyepsdnjcv2kzyav5ze0ta7n67

all other inputs were send One block after, this look really oddly looks like bot misconfigured but anyway, that already happened and we only can speculate with it

If the btc was truly taken by bots, then the original finder of 66 is a DUMMY, lol. I gave them step by step instructions on how to avoid the bots. If that is the case and the btc was stolen, they must be on su*cide watch by now.

Also, stop taking your bot offline albert0!!! lol.

For the database, I was able to use it with a faster version of BSGS versus the one mcd first put out on repo, but python only. So it was still "slow" compared to yours or others written in C++/PB, but it was able to use the smaller db with no issues.

[COBRAS]

Yes i remember that database, the idea is cool, but as we me talk before the problem is the search speed, I think in different workarounds over that idea but none of them was efficient, I am going to think on it again, maybe some mix between a custom bloom-filter and some bit rotation can make it work, but I don't know final speed until I test it.

And if that database works, it can't be used with kangaroo, but it can be used with BSGS. If anyone wants to work with that idea please let me know.

By the way. I think that the puzzle66 Original transaction was actually replaced by someone, look:

There is a older transaction with less fee: 8c8ec6b3511c62500ea9b3a1c30ca937e15d251b55d30290a2a6da2f1124f3fb



It has only 5.22 sat/vB and all the inputs the destination address was: 1Jvv4yWkE9MhbuwGUoqFYzDjRVQHaLWuJd


   
But it was replaced 45 seconds after with the Mined TX: 57a88f47e4c047740b782a5562fca143ce85de0373cbff3a7d406e9ae7fc2f5f



That TX is 406 sat/vB and only has one input to a different address: bc1qpkp47q5cucrvnyepsdnjcv2kzyav5ze0ta7n67

all other inputs were send One block after, this look really oddly looks like bot misconfigured but anyway, that already happened and we only can speculate with it


l

If was previous transaction 100% prise was stolen by another user with another "specialisation". Does yours bot was really offline ? ))

[citb0in]

@COBRAS:

### AVOID FULL QUOTING AND CONSECUTIVE POSTS AND STICK TO THE FORUM RULES ###

[frozenen]

Congrats to whoever pocketed #66, if bots got it then maybe finder never followed this forum which was mistake, should of attempted the slipstream mara idea!
At least now I know I was way off, was convinced it was in 34XXXXXXXXXXXXXXX

[AliBah]

The private key 0x2832ed74f2b5e35ee is at 25.62167438642828% of the range

[CY4NiDE]

I'm speechless. Someone really just sent the public key to the mempool all willy nilly

Regardless of the poor bastard being in the forum or not, I'll leave this here;

While your bruteforce tools are running go and actually study what the heck you are doing, peoples.