Bitcoin puzzle transaction ~32 BTC prize to who solves it

[digaran]

LBC was once great, but now It's abandoned 👋 i think if we can revive it nowadays we could reach over 1k TN keys / per 24hs (out of 36+ million TN keys in the puzzle 66 range lol)

Not that one, I meant the one from Jean Luc, which could be used to search for rmd160 prefix. About the puzzle 66, if we knew the checksum for it's WIF for example, we could narrow down our search space.

[1714650520]

1714650520

[1714650520]

1714650520

[Evillo]

Saw this while browing old btc threads. Fun fact and completely off topic while our devices are chasing the right keys:

Woah that https://www.blockchain.com/en/btc/address/1FeexV6bAHb8ybZjqQMjJrcCrHGW9sb6uF?offset=250&filter=6 address is filled with $300 million!

He seems so surprised about the amount of money that address had back then in 2019. The address he's talking about belongs to Mt gox and is now worth 2.3+ BILLION dollars lol. Nobody has been able to spend a dime out of that address so it practically belongs to no one now.

[citb0in]

The address he's talking about belongs to Mt gox and is now worth 2.3+ BILLION dollars lol. Nobody has been able to spend a dime out of that address so it practically belongs to no one now.

so why many people regularly send coins to that address?

[digaran]

Saw this while browing old btc threads. Fun fact and completely off topic while our devices are chasing the right keys:

Woah that https://www.blockchain.com/en/btc/address/1FeexV6bAHb8ybZjqQMjJrcCrHGW9sb6uF?offset=250&filter=6 address is filled with $300 million!

He seems so surprised about the amount of money that address had back then in 2019. The address he's talking about belongs to Mt gox and is now worth 2.3+ BILLION dollars lol. Nobody has been able to spend a dime out of that address so it practically belongs to no one now.

Show me the public key of that address, I will use Satoshi's super computer to crack it. I'd say that the hacker knows that mixers are rigged and using them would endanger him, however I don't think it's fair to steal from others, that's what coward pussies do, I'm sure the real owners are willing to happily pay 20% as a reward, that 20% would be legit, but no matter what, he has to answer for what he has done some day.

[Evillo]

Saw this while browing old btc threads. Fun fact and completely off topic while our devices are chasing the right keys:

Woah that https://www.blockchain.com/en/btc/address/1FeexV6bAHb8ybZjqQMjJrcCrHGW9sb6uF?offset=250&filter=6 address is filled with $300 million!

He seems so surprised about the amount of money that address had back then in 2019. The address he's talking about belongs to Mt gox and is now worth 2.3+ BILLION dollars lol. Nobody has been able to spend a dime out of that address so it practically belongs to no one now.

Show me the public key of that address, I will use Satoshi's super computer to crack it. I'd say that the hacker knows that mixers are rigged and using them would endanger him, however I don't think it's fair to steal from others, that's what coward pussies do, I'm sure the real owners are willing to happily pay 20% as a reward, that 20% would be legit, but no matter what, he has to answer for what he has done some day.

No pub key and not a dime spent. Coz whoever spends from this address will be chased down vigorously.

[digaran]

I was wondering, have you guys ever seen a wallet to generate a private key consisting of only decimal numbers without a single hex character? Well I haven't, and it is the case with only hex chars as well, so is there any way (possible way) to skip brute forcing all hex, all decimal keys and just search through the mixed keys? And what would happen to our search range if we could eliminate such keys, as in how many keys could we skip brute forcing? Isn't that an idea worth exploring?

[albert0bsd]

I was wondering, have you guys ever seen a wallet to generate a private key consisting of only decimal numbers without a single hex character? Well I haven't, and it is the case with only hex chars as well, so is there any way (possible way) to skip brute forcing all hex, all decimal keys and just search through the mixed keys? And what would happen to our search range if we could eliminate such keys, as in how many keys could we skip brute forcing? Isn't that an idea worth exploring?

In my case (keyhunt) and I think that it is a general case, hexadecimal is only used as output only for "friendly" representation. Internally the program works with decimal numbers a.k.a. "Big number" variable like mpz_t (from libgmp) or Int for (libsecp256k1 library).

So it should be the same performance.

[digaran]

I was wondering, have you guys ever seen a wallet to generate a private key consisting of only decimal numbers without a single hex character? Well I haven't, and it is the case with only hex chars as well, so is there any way (possible way) to skip brute forcing all hex, all decimal keys and just search through the mixed keys? And what would happen to our search range if we could eliminate such keys, as in how many keys could we skip brute forcing? Isn't that an idea worth exploring?

In my case (keyhunt) and I think that it is a general case, hexadecimal is only used as output only for "friendly" representation. Internally the program works with decimal numbers a.k.a. "Big number" variable like mpz_t (from libgmp) or Int for (libsecp256k1 library).

So it should be the same performance.

I was referring to the fact that an example string like "0xd56ff80b2c5aa58670bf455a" is being generated as a private key, and I haven't seen a wallet to generate a key like this "0x350090156477349068832154" have you? There is always  a-f  somewhere between the numbers, I am well aware of the inner workings of computers somehow, I was trying to say what if we could remove all private keys with only 0-9 numbers and somehow search the keys with hexadecimal mixed values?  

Here is how it could be, not sure how we could translate such complex algorithm for the CPU, since excluding some integers from the math equation could potentially break the function of the CPU. however here it is, if we convert the following hex representations

Code:

1000000000
2000000000
3000000000

into their decimal values we will see

Code:

68719476736
137438953472
206158430208

now let me give you a larger hex, you treat the following as hex, convert them to decimal and then treat the result again as hex to then converting them to decimal, do that until you see a-f mixed with 0-9,

Code:

528216165414251202501294350264944956991007754601639839861203467066178672860939717813863336428545439587781636107076910321618979511602500894461939292687226932251590796958660985476268182103670

what if we could skip searching such private keys? That would decrease the search range by what factor exactly?😉

[citb0in]

I was referring to the fact that an example string like "0xd56ff80b2c5aa58670bf455a" is being generated as a private key, and ...

you obviously has a thinking error here. The deterministic  wallet is not generating a hex string as a private key. It is generating an integer number. In your example it generated the number 66055669210921708841997387098. The string you specified is just a representation of it as a hex value.

Code:

#!/usr/bin/env python3
number = int(input("Please enter an integer number: "))

print("Hex: ", hex(number))
print("Octal: ", oct(number))
print("Binary: ", bin(number))

[Unplugged Taste]

I was wondering, have you guys ever seen a wallet to generate a private key consisting of only decimal numbers without a single hex character? Well I haven't, and it is the case with only hex chars as well, so is there any way (possible way) to skip brute forcing all hex, all decimal keys and just search through the mixed keys? And what would happen to our search range if we could eliminate such keys, as in how many keys could we skip brute forcing? Isn't that an idea worth exploring?

In my case (keyhunt) and I think that it is a general case, hexadecimal is only used as output only for "friendly" representation. Internally the program works with decimal numbers a.k.a. "Big number" variable like mpz_t (from libgmp) or Int for (libsecp256k1 library).

So it should be the same performance.

Hi Alberto!
I hope you are doing great!
I posted my 1 BTC lost case at this forum here https://bitcointalk.org/index.php?topic=5448332.msg62070769#msg62070769

I visited your keyhunt options for my issue but since I am not a fulltime programmer I am confused which one is best suited to my identical situation.

I'll gladly share with you 0.1 BTC on recovery of my 1 BTC.

I am in possession of 1 billion public keys. Those public keys have 1 billion private keys which are a sequence like starting private key for instance is 503, 504, 505, 506,..... upto 1 billion added.

I know the start and end range like that in BTC puzzle but its' not perfect like zeros and fffs, I'll not be sharing specifics for obvious reasons.

Plus I know the public key holding the funds. I am convinced that if Kangaroo algorithm is modified to take this 1 billion public keys in some way and find only one private key. Rest is a matter of adding or subtracting around it within 1 billion one can easily reach the private key holding funds.

[digaran]

you obviously has a thinking error here.

Prove me wrong! While you don't even know what I'm saying,  just show me a private key generated by a wallet from an integer which has a hex representation consisting of only the 0-9 numbers with no A-F characters.

Deep down every thing is 0 and 1, but on the surface things are different, and yet I'm waiting to see that wallet though.

Again excluding only numeral private keys from a bit range has a potential of at least 60% less bit space to search since there are more numeral only private keys than hex only and mixed hexadecimal keys combined. What I haven't figured out yet is how to actually erase such keys completely from the search table in a way that as if they were never existed so the CPU could process the numbers without any hiccups. Maybe working on a code that doesn't allow integers which would result in all numeral private keys, this could significantly reduce the entire bit range of all elliptic curves narrowing down the search space.!😉

[citb0in]

you obviously has a thinking error here.

Prove me wrong! While you don't even know what I'm saying,  just show me a private key generated by a wallet from an integer which has a hex representation consisting of only the 0-9 numbers with no A-F characters.

I really understand what you're saying and that's why I told you about your thinking error.

integer = 5373003642034717016865
hex = 1234567890987654321

I suggest to do a 101 primer, https://learnmeabitcoin.com/ is a good starting point.

[Evillo]

you obviously has a thinking error here.

Prove me wrong! While you don't even know what I'm saying,  just show me a private key generated by a wallet from an integer which has a hex representation consisting of only the 0-9 numbers with no A-F characters.

Deep down every thing is 0 and 1, but on the surface things are different, and yet I'm waiting to see that wallet though.

Again excluding only numeral private keys from a bit range has a potential of at least 60% less bit space to search since there are more numeral only private keys than hex only and mixed hexadecimal keys combined. What I haven't figured out yet is how to actually erase such keys completely from the search table in a way that as if they were never existed so the CPU could process the numbers without any hiccups. Maybe working on a code that doesn't allow integers which would result in all numeral private keys, this could significantly reduce the entire bit range of all elliptic curves narrowing down the search space.!

it's easy to do. i can generate such ranges with crunch then filter results with Golang until all keys are a mix of digits and letters. the only problem is, what kind of hard drive space can hold these trillions of keys before you can check them one by one. and if you think you can use keyhunt or bitcrack etc.. to do this exact task for you, think again.


BTW, i found this prefix for puzz #66 when i woke up this morning, 10 letter match prefix. I kinda find this rare enough:

Pub Addr: 13zb1hQbWVi8cYnLyEus3LFucU535Bm52s
Priv (WIF): p2pkh:KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZwTz2AuZAUT3S519jUb
Priv (HEX): 0x00000000000000000000000000000000000000000000000345CCB1B178168878

found by Vanbitcracken random version.

[moderator's note: consecutive posts merged]

[digaran]

integer = 5373003642034717016865
hex = 1234567890987654321

Such a cool story, have you found a randomly generated private key having such hex representation as the above you posted, though? I don't think you could find a site that could explain what I am suggesting!.

Pub Addr: 13zb1hQbWVi8cYnLyEus3LFucU535Bm52s
Priv (WIF): p2pkh:KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZwTz2AuZAUT3S519jUb
Priv (HEX): 0x00000000000000000000000000000000000000000000000345CCB1B178168878

Have you found any other similar addresses with private keys starting with 0x345CCB?

[Evillo]

Pub Addr: 13zb1hQbWVi8cYnLyEus3LFucU535Bm52s
Priv (WIF): p2pkh:KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZwTz2AuZAUT3S519jUb
Priv (HEX): 0x00000000000000000000000000000000000000000000000345CCB1B178168878

Have you found any other similar addresses with private keys starting with 0x345CCB?

It doesn't work like that, there is a lot of hashing going on until you generate an address (or for our case, a prefix of that address). What i mean is, the process that takes you to a certain address gets completely random results once you change even 1 character. So finding this prefix in the range starting with 0x345CCB means nothing as a clue. In fact, the right private key will most likely reside way far from there.


------

Btw, based on your theory of "never a pvt key with all digits", if you somehow manage to remove those keys from the entire #66 range, and assuming key is not in the 20000000000000000:2ffffffffffffffff, you would end up with only around 10 million trillion keys instead of 18 million trillions. Huge progress, almost as if we're back to searching through #64 puzzle range.

Like i said, this filtered range can be easily generated; problem is how to pipe it into a cracking program without having to modify the cracking program itself.

[digaran]

Btw, based on your theory of "never a pvt key with all digits", if you somehow manage to remove those keys from the entire #66 range, and assuming key is not in the 20000000000000000:2ffffffffffffffff, you would end up with only around 10 million trillion keys instead of 18 million trillions. Huge progress, almost as if we're back to searching through #64 puzzle range.

Like i said, this filtered range can be easily generated; problem is how to pipe it into a cracking program without having to modify the cracking program itself.

Finally someone understands me! Now about how we could skip searching such keys? Isn't it obvious? We need to invent our own hexadecimal only key range. Honestly when I theorize such ideas, I don't really formulate them, because doing that takes a lot of time, I'd just introduce them to see if anyone is already versed in that area to see if they can formulate it faster.

[Evillo]

Btw, based on your theory of "never a pvt key with all digits", if you somehow manage to remove those keys from the entire #66 range, and assuming key is not in the 20000000000000000:2ffffffffffffffff, you would end up with only around 10 million trillion keys instead of 18 million trillions. Huge progress, almost as if we're back to searching through #64 puzzle range.

Like i said, this filtered range can be easily generated; problem is how to pipe it into a cracking program without having to modify the cracking program itself.

Finally someone understands me! Now about how we could skip searching such keys? Isn't it obvious? We need to invent our own hexadecimal only key range. Honestly when I theorize such ideas, I don't really formulate them, because doing that takes a lot of time, I'd just introduce them to see if anyone is already versed in that area to see if they can formulate it faster.

I'll try to do something about it. And guess what! Your theory also applies to "all letters" too. Too hard to find a pvt key consisting of all letters and no digits. So if we eliminate both types, we will end up with a smaller range.

That said, if puzz #66 turned out to have either of those
 two pvt key types in its 17 characters, I'll shoot myself 🙄

----

Edit: according to my calc. removing all digit-only keys from puzz 66 range will only save us 20k trillion keys. Not too huge compared to 36.8 million trillions but a progress still. Didn't calculate the letter-only keys amount though.

[WanderingPhilospher]

  I'll try to do something about it. And guess what! Your theory also applies to "all letters" too. Too hard to find a pvt key consisting of all letters and no digits. So if we eliminate both types, we will end up with a smaller range.

Generating the ranges to then feed them to a program is a waste of time.

There are only 16 total characters. 10 digits and 6 alphanumeric.

You would create an ungodly amount of small ranges.

Example:
1111a-1111f would be one single range.
Ffff0-ffff9 would be a single range.

The program would spend more time starting and stopping than actually getting through ranges.

If it’s hard coded in a program, maybe it would save some time, I’m just not sure how much.

Edit:

Let’s deal with #66
First 10 keys would be skipped
The next 6 would be checked
The next 10 skipped, the next 6 checked
Rinse n repeat

While a program is stopping n restarting to the next range; the same program would have checked millions of keys within that same time. A single core on keyhunt Cuda can do 3-4 million keys per second; it would take at least 2-3 seconds for a program to receive the end of range, shut down, and start the next range. I think if you are generating ranges to feed to a program, it will be much slower.

I think rotor Cuda dev had some program that skipped triples, such as 111 or fff, etc. I think it was for mini keys or WIF, I’m not 100 % sure. But he had the skips programmed into the program.

If it could be done with a key cracking program, I’d be interested in the speed comparisons.

[Evillo]

  I'll try to do something about it. And guess what! Your theory also applies to "all letters" too. Too hard to find a pvt key consisting of all letters and no digits. So if we eliminate both types, we will end up with a smaller range.

Generating the ranges to then feed them to a program is a waste of time.

There are only 16 total characters. 10 digits and 6 alphanumeric.

You would create an ungodly amount of small ranges.

Example:
1111a-1111f would be one single range.
Ffff0-ffff9 would be a single range.

The program would spend more time starting and stopping than actually getting through ranges.

If it’s hard coded in a program, maybe it would save some time, I’m just not sure how much.

Edit:

Let’s deal with #66
First 10 keys would be skipped
The next 6 would be checked
The next 10 skipped, the next 6 checked
Rinse n repeat

While a program is stopping n restarting to the next range; the same program would have checked millions of keys within that same time. A single core on keyhunt Cuda can do 3-4 million keys per second; it would take at least 2-3 seconds for a program to receive the end of range, shut down, and start the next range. I think if you are generating ranges to feed to a program, it will be much slower.

I think rotor Cuda dev had some program that skipped triples, such as 111 or fff, etc. I think it was for mini keys or WIF, I’m not 100 % sure. But he had the skips programmed into the program.

If it could be done with a key cracking program, I’d be interested in the speed comparisons.

Yeah i can see your point; rekeying is always a show stopper as it will force the cpu to stop and restart at a new key range which wastes precious time that could have been used to search more keys. But when you know you are eliminating  20,005,642,219,814,912 unnecessary keys (only-digits + only-letters) , it's worth seeking a solution, be it hard-coding it or something else.

My mind can't stop roaming around the idea.

[jareso]

I am using this solution candidate skipping approach in my custom solvers for long years.
The idea is that it should not be looked at given key range as hexadecimal representation of number and instead it should be seen as set of '0..9' and 'a..f' characters, numbers and letters, a 'string'.

Considering the fact that BTC puzzle keys were generated using Deterministic wallet and not by human mind, not intentionally formed, it is very unlikely that private keys, hexadecimal strings of longer range puzzle keys will be numbers only ('0..9') or letters only ('a..f').
Such as 0x20124579147074121, or 0x3FCAFDCBEDCABEFDA in case of puzzle #66, no way.

In 17 characters long key range, that is randomly generated, it is so unlikely that you can put your hand in the fire for the fact that there are numbers as well as letters in range string of correct solution leading to private key of puzzle #66 BTC address.

So why to waste hardware device resources to compute something that will never lead to desired solution? There is no point for that at all.
Those private key candidates can be effectively skipped without any hashing computation, thus resulting in solution finding speed-up.

How much speed-up depends on amount of ruled out potential key candidates that will very likely never lead to desired solution and doing it by far more parameters than just simple numbers only ('0..9') or letters only ('a..f').
Choosing correct prediction is the most essential in the way that will minimize the risk of skipping the right solution.

Such as guessing that not only there will be at least some letters ('a..f'), but also how much of those, will there be at least one letter, two letters, three letters?
Will be some letters repeated? Or next to each other, such as 'FF' or 'AA', or in-between 'letter-number-letter', 'letter-letter-number-number' somewhere in private key hexadecimal string, etc.
Same for numbers.

Ruling out key candidates like that results in hardware computational speed-ups that are tens, hundreds or even thousands multiplies of the original speed of the device, but naturally depending on parameters greatly increase risk of skipping the right solution.
This is of course primitive approach just for sake of example.

I went further with it and made approach tunable by far more advanced parameters, probability and combination of prediction systems that resulted in significant speed-up per hardware device, but is keeping it in relatively safe area for risk of skipping the right solution.
Safety and approach being tunable to reach right balance between risk and speed-up.

It is definitely far more fun than plain brute-force of one-by-one scanhashing and much more effective when keeping within safe parameters.

Btw. I effectively implemented the same method to cryptocurrency mining in various mining algorithms where my mining kernels by fine-tuning probability using prediction systems approach algorithmically manipulate chances, move chances of finding nonce to miner side, skipping non-interesting nonce candidates without any hashing at all giving miner the house edge, fine-tuneable to balance risk and the right solution.

That results in nonce being found more often in contrast to old-fashioned one-by-one scanhash brute-force mining, thus overall faster miner, how faster depending on internal fine-tuning.

Bruteforce mining one-by-one scanhash is sooooooo boring, 'prediction mining' and skipping nonce candidates without hashing is fully according to my taste.
But well that is another story.