Bitcoin puzzle transaction ~32 BTC prize to who solves it

[brainless]

The process for finding puzzle slow now a days due to price of btc
As in past 71 puzzle had 0.7 btc reward changed to 7.1 btc reward
If now remaining puzzle extend price example 7.1 btc to 71 btc, you will see 71 to 100 bit puzzle would be found in a year
But creator maybe bring pubkey publish from 126 to 160
What's your expectations?

[fecell]

The process for finding puzzle slow now a days due to price of btc
As in past 71 puzzle had 0.7 btc reward changed to 7.1 btc reward
If now remaining puzzle extend price example 7.1 btc to 71 btc, you will see 71 to 100 bit puzzle would be found in a year
But creator maybe bring pubkey publish from 126 to 160
What's your expectations?

no one pubkey, never.

[ExernalVN]

I’ve been testing some of the older/easier puzzles using three different rigs with a VanitySearch mod one fast, one medium, and one painfully slow. What’s interesting is how big the luck component is once you’re searching large spaces. What I mean is the fast machine doesn't always solve the puzzle the fastest or even at a predictable lead or gap ahead than the others. Luck, for lack of a better word, seems to matter more then pure guesses once you get up to the larger spaces.

I highly disagree. If you run those puzzles over long runs (thousands of tries) you will find the solution sooner or later every single time, but, on average, it is very clear that what emerges is the expected average solve time (relative to a rig's speed of course) which is right at 50% of maximum work needed. And that expected average solve time will naturally double up for every incremental puzzle, it is not jumping all over the place, as you suggest. Thus, the "luck factor" as you call it, also halves every time the search space doubles.

Hi, do you scaning right now ? and if it's not secret, on which range you scanning ?

[brainless]

I’ve been testing some of the older/easier puzzles using three different rigs with a VanitySearch mod one fast, one medium, and one painfully slow. What’s interesting is how big the luck component is once you’re searching large spaces. What I mean is the fast machine doesn't always solve the puzzle the fastest or even at a predictable lead or gap ahead than the others. Luck, for lack of a better word, seems to matter more then pure guesses once you get up to the larger spaces.

I highly disagree. If you run those puzzles over long runs (thousands of tries) you will find the solution sooner or later every single time, but, on average, it is very clear that what emerges is the expected average solve time (relative to a rig's speed of course) which is right at 50% of maximum work needed. And that expected average solve time will naturally double up for every incremental puzzle, it is not jumping all over the place, as you suggest. Thus, the "luck factor" as you call it, also halves every time the search space doubles.

Hi, do you scaning right now ? and if it's not secret, on which range you scanning ?

When brute force methods in development, I recommend batch jump for random  search, still after 7 years there is no development in this little tweak in all apps, still single digit random or wise versa,
Check and stride subject could by used with math for finding 71 and above
Still option available with little modified bitcrack and 5090 gpu and 71 could come out with 3 to 7 days
Think out of the box

[ExernalVN]

I’ve been testing some of the older/easier puzzles using three different rigs with a VanitySearch mod one fast, one medium, and one painfully slow. What’s interesting is how big the luck component is once you’re searching large spaces. What I mean is the fast machine doesn't always solve the puzzle the fastest or even at a predictable lead or gap ahead than the others. Luck, for lack of a better word, seems to matter more then pure guesses once you get up to the larger spaces.

I highly disagree. If you run those puzzles over long runs (thousands of tries) you will find the solution sooner or later every single time, but, on average, it is very clear that what emerges is the expected average solve time (relative to a rig's speed of course) which is right at 50% of maximum work needed. And that expected average solve time will naturally double up for every incremental puzzle, it is not jumping all over the place, as you suggest. Thus, the "luck factor" as you call it, also halves every time the search space doubles.

Hi, do you scaning right now ? and if it's not secret, on which range you scanning ?

When brute force methods in development, I recommend batch jump for random  search, still after 7 years there is no development in this little tweak in all apps, still single digit random or wise versa,
Check and stride subject could by used with math for finding 71 and above
Still option available with little modified bitcrack and 5090 gpu and 71 could come out with 3 to 7 days
Think out of the box

i am using jumps with random, i just set first 2 symbols, for example 4f, all others is random + speed of my GPU * time of scanning
BUT you said 5090 and #71 3-7 days, its impossible, or need too much lucky.
OR it was means x5090 GPUs ?)))

[brainless]

I’ve been testing some of the older/easier puzzles using three different rigs with a VanitySearch mod one fast, one medium, and one painfully slow. What’s interesting is how big the luck component is once you’re searching large spaces. What I mean is the fast machine doesn't always solve the puzzle the fastest or even at a predictable lead or gap ahead than the others. Luck, for lack of a better word, seems to matter more then pure guesses once you get up to the larger spaces.

I highly disagree. If you run those puzzles over long runs (thousands of tries) you will find the solution sooner or later every single time, but, on average, it is very clear that what emerges is the expected average solve time (relative to a rig's speed of course) which is right at 50% of maximum work needed. And that expected average solve time will naturally double up for every incremental puzzle, it is not jumping all over the place, as you suggest. Thus, the "luck factor" as you call it, also halves every time the search space doubles.

Hi, do you scaning right now ? and if it's not secret, on which range you scanning ?

When brute force methods in development, I recommend batch jump for random  search, still after 7 years there is no development in this little tweak in all apps, still single digit random or wise versa,
Check and stride subject could by used with math for finding 71 and above
Still option available with little modified bitcrack and 5090 gpu and 71 could come out with 3 to 7 days
Think out of the box

i am using jumps with random, i just set first 2 symbols, for example 4f, all others is random + speed of my GPU * time of scanning
BUT you said 5090 and #71 3-7 days, its impossible, or need too much lucky.
OR it was means x5090 GPUs ?)))

I did not say random
I said numbers of key check and stride mean jump
Plus calc math methods

[optioncmdPR]

I’ve been testing some of the older/easier puzzles using three different rigs with a VanitySearch mod one fast, one medium, and one painfully slow. What’s interesting is how big the luck component is once you’re searching large spaces. What I mean is the fast machine doesn't always solve the puzzle the fastest or even at a predictable lead or gap ahead than the others. Luck, for lack of a better word, seems to matter more then pure guesses once you get up to the larger spaces.

You’d think raw speed would always dominate, but past a certain point it's almost like a lottery. The slow rig can get lucky and land something early, while the fast one goes dry for a while.

Makes me think the winner of Puzzle 71 might just be whoever the randomness smiles on that day.

I completely agree, the space where the key is located is gigantic. I wonder who solved 69 and how they did it.
I've been looking at this forum for months and trying different methods. I took the last 36 keys and extracted patterns that haven't been seen in the keys. According to my calculations, there are approximately 500 million left. I don't know if anyone has an idea to improve the one I'm presenting. And don't gamble 100% on the lottery with puzzle 71

  Elaborate on this ? You said " I don't know if anyone has an idea to improve the one I'm presenting," without presenting any findings, theories, or ideas other than you extracted patterns that haven't been seen. I say this because use of a last 36 address is something I have been experimenting with.

[brainless]

Let me clarify
Ecc operations have 1 bit only
Your 1 move is 0, so you can't take step for reverse , mean if you step back or fw is 0
Example
If you give me any of your pubkey, I will extract 1 bit and give you back new pubkey
You can test yourself
My given pubkey by extract 1 bit
You will substract you key, , multiply by xxxxxx,
You will see new pubkey back at first pubkey
You repeats unlimited counts
Always you backed at 1st pubkey
Mean 1 bit loop never let you move anywhere

[mdemon69]

I’ve been testing some of the older/easier puzzles using three different rigs with a VanitySearch mod one fast, one medium, and one painfully slow. What’s interesting is how big the luck component is once you’re searching large spaces. What I mean is the fast machine doesn't always solve the puzzle the fastest or even at a predictable lead or gap ahead than the others. Luck, for lack of a better word, seems to matter more then pure guesses once you get up to the larger spaces.

I highly disagree. If you run those puzzles over long runs (thousands of tries) you will find the solution sooner or later every single time, but, on average, it is very clear that what emerges is the expected average solve time (relative to a rig's speed of course) which is right at 50% of maximum work needed. And that expected average solve time will naturally double up for every incremental puzzle, it is not jumping all over the place, as you suggest. Thus, the "luck factor" as you call it, also halves every time the search space doubles.

Hi, do you scaning right now ? and if it's not secret, on which range you scanning ?

When brute force methods in development, I recommend batch jump for random  search, still after 7 years there is no development in this little tweak in all apps, still single digit random or wise versa,
Check and stride subject could by used with math for finding 71 and above
Still option available with little modified bitcrack and 5090 gpu and 71 could come out with 3 to 7 days
Think out of the box

i am using jumps with random, i just set first 2 symbols, for example 4f, all others is random + speed of my GPU * time of scanning
BUT you said 5090 and #71 3-7 days, its impossible, or need too much lucky.
OR it was means x5090 GPUs ?)))

I did not say random
I said numbers of key check and stride mean jump
Plus calc math methods

Ok, let's suppose you have a tool (a modified VanitySearch) that works with an option for stride, what would be you're search strategy, if I may ask?

[Cricktor]

Consider me an interested bystander. I'm just curious what strategies, algorithms and whatnot else you all come up with (besides a lot of nonsense^{to me} that's unfortunately constantly posted).

In my humble opinion, if you have only one or few GPUs at your disposal and are able and want to risk the energy costs to operate them, you definitely lack number crunching power to reasonably compete in finding any remaining puzzle's key solution. So, I guess your "only" option is a lucky punch, you gamble to choose a more or less randomly selected sub-region (within the search space of the particular puzzle you're trying to solve) to search for a solution. You keep track of sub-regions you exhausted in your searches to avoid crunching on a sub-region again, especially when those are chosen randomly.

It's basically some kind of lottery. As you have no reasonable chance to seriously compete with your way-insufficient GPU power, so perhaps the goddess of fortune is smiling on you?

I'm not intensely following things with this puzzle because skipping the nonsense is a bit exhausting and ignoring accounts here does help somewhat when I judge that they're mostly polluting this thread with garbage. I also don't have time and enough programming expertise to code or extensively modify existing tools.

Above lottery idea might be a total stupid one. Feel free to explain why or come up with something better then!

If it's not stupid (you judge!) then we have another playground opened: strategies to choose the sub-regions (size, how to pick).

A quick shot at how I would implement it:
* some control instance that chooses the sub-regions and keeps track which have been exhaustively searched
* worker(s) that search assigned sub-regions as good and quick as possible

I would want the worker instance to do the search in such a way that when no solution is found in a sub-region that this result is 100% accurate. It's a lottery search anyway.

[kTimesG]

A quick shot at how I would implement it:
* some control instance that chooses the sub-regions and keeps track which have been exhaustively searched
* worker(s) that search assigned sub-regions as good and quick as possible

I would want the worker instance to do the search in such a way that when no solution is found in a sub-region that this result is 100% accurate. It's a lottery search anyway.

That's how Bram solved 67 and 68. Pretty much the only way to actually solve a puzzle (the alternative is to post intellectual garbage, of course).

The only issue with "100% accurate" is that, for address puzzles, it's impossible to implement, because each and every hash candidate is independent of all others. So, even the smallest bug in the entire pipeline (pubkey -> sha512 -> ripemd) can compromise the result, without ever being detected, even when using statistical sampling.

I forgot, all tools are bullet-proof bug-free, obviously, and definitely obscure bugs like missing the third reduction step during EC field multiplication (like in all JLP-based forks) can never occur, lol.

[fixedpaul]

The only issue with "100% accurate" is that, for address puzzles, it's impossible to implement, because each and every hash candidate is independent of all others. So, even the smallest bug in the entire pipeline (pubkey -> sha512 -> ripemd) can compromise the result, without ever being detected, even when using statistical sampling.

I forgot, all tools are bullet-proof bug-free, obviously, and definitely obscure bugs like missing the third reduction step during EC field multiplication (like in all JLP-based forks) can never occur, lol.

You are 100% right on this, But, as for the probabilty of this "bug" ever showing up: it's insanely small. For a single key, the chance is 5*4.294.966.319/2**256 roughly one in about 10**67. Realistically, you’d need to scan around 2**222 keys before you’d expect to see this event. The probability that the "winning key" specifically is the one affected by this bug is again around 10**-67

So honestly, the odds that this "bug" would invalidate the entire search are practically zero. Still, you're absolutely right, we can't technically claim 100%

Do you think it makes sense to implement a check that would slow down the process, given that the probability is practically zero?

[kTimesG]

Do you think it makes sense to implement a check that would slow down the process, given that the probability is practically zero?

When there are zillions of field multiplications, and I'm investing vast amounts of resources, then absolutely yes. A few cycles of doing a carry-over is better than an invisible data corruption that might or might not have cascade effects.

Not sure how you got to that number. In the paper I'm reading, sloppy reduction has a r(r-1)/2N chance of being incorrect after only two reductions. Since r is 33 bits, this gives something around one in 2**190.

[fixedpaul]

Do you think it makes sense to implement a check that would slow down the process, given that the probability is practically zero?

When there are zillions of field multiplications, and I'm investing vast amounts of resources, then absolutely yes. A few cycles of doing a carry-over is better than an invisible data corruption that might or might not have cascade effects.

Not sure how you got to that number. In the paper I'm reading, sloppy reduction has a r(r-1)/2N chance of being incorrect after only two reductions. Since r is 33 bits, this gives something around one in 2**190.

Actually, I just made a very simple reasoning about the probability that, in the final reduction, the 256-bit number ends up being greater than p, and then taking into account the average number of modmult operations per key, but maybe I oversimplified it. Assuming we're even talking about the same issue.

I also didn’t consider the "cascade effect", meaning that if the bug happens, it would invalidate all subsequent keys computed by that thread, given how VanitySearch works.

Anyway, as soon as I have some time, I’ll try to implement a check on the final reduction in my repo. Thanks for pointing it out.

[kTimesG]

Assuming we're even talking about the same issue.

We are.

https://eprint.iacr.org/2021/1151.pdf

Section 4.1

[brainless]

I’ve been testing some of the older/easier puzzles using three different rigs with a VanitySearch mod one fast, one medium, and one painfully slow. What’s interesting is how big the luck component is once you’re searching large spaces. What I mean is the fast machine doesn't always solve the puzzle the fastest or even at a predictable lead or gap ahead than the others. Luck, for lack of a better word, seems to matter more then pure guesses once you get up to the larger spaces.

I highly disagree. If you run those puzzles over long runs (thousands of tries) you will find the solution sooner or later every single time, but, on average, it is very clear that what emerges is the expected average solve time (relative to a rig's speed of course) which is right at 50% of maximum work needed. And that expected average solve time will naturally double up for every incremental puzzle, it is not jumping all over the place, as you suggest. Thus, the "luck factor" as you call it, also halves every time the search space doubles.

Hi, do you scaning right now ? and if it's not secret, on which range you scanning ?

When brute force methods in development, I recommend batch jump for random  search, still after 7 years there is no development in this little tweak in all apps, still single digit random or wise versa,
Check and stride subject could by used with math for finding 71 and above
Still option available with little modified bitcrack and 5090 gpu and 71 could come out with 3 to 7 days
Think out of the box

i am using jumps with random, i just set first 2 symbols, for example 4f, all others is random + speed of my GPU * time of scanning
BUT you said 5090 and #71 3-7 days, its impossible, or need too much lucky.
OR it was means x5090 GPUs ?)))

I did not say random
I said numbers of key check and stride mean jump
Plus calc math methods

Ok, let's suppose you have a tool (a modified VanitySearch) that works with an option for stride, what would be you're search strategy, if I may ask?

Math + modified bitcrack + 5096 gpu

[Al-Kindi]

The inventor of this puzzles name is In this hash 41932e0d52a2b1e171d28f6b442981137790bcbf1d72201bea441f36fd7ba67b I just want to say, Hi, ⁤⁣⁤‍⁡‍‍⁣‍⁡‌⁢‍⁤⁡⁢⁡‍⁡‍⁢⁣‍‌‍⁢‍⁤⁡⁢⁡⁢⁡‍‌‌⁡‍‌‍⁢‍⁡‌⁡‌⁡⁤‍⁤⁡⁤⁣‌⁢‌⁡‍‍‌⁢‍⁤⁡⁢‍⁢⁡‍‌‌⁡‌⁡‌⁢‍⁤⁡⁢‍⁡⁢‍⁤⁡⁢⁡⁢⁡‍‍⁣‍⁡⁤‍⁤⁡⁢‍⁣‌⁡⁤‍‌‍Hello

Having that person be the author (big fan of him) kind of hurts the case of my pet project which had great potential - do you have hard evidence?

[Tshiwh]

Let me clarify
Ecc operations have 1 bit only
Your 1 move is 0, so you can't take step for reverse , mean if you step back or fw is 0
Example
If you give me any of your pubkey, I will extract 1 bit and give you back new pubkey
You can test yourself
My given pubkey by extract 1 bit
You will substract you key, , multiply by xxxxxx,
You will see new pubkey back at first pubkey
You repeats unlimited counts
Always you backed at 1st pubkey
Mean 1 bit loop never let you move anywhere

Tried to build X pubkey 135 using GX as started point, done the calculations manually for the whole 64byts, GX * I to get first 4bits of the pubkey, then i*16 (±31) * GX to get second 4bit .....
After ending with X1 wich is egal to X extended to 500±bits then (X1/64**16)/GX = exactly GX/X
So key that should be explored is the ±31 or maybe should be reduced to ±16 to get hex value from 0 to f

[fecell]

Let me clarify
Ecc operations have 1 bit only
Your 1 move is 0, so you can't take step for reverse , mean if you step back or fw is 0
Example
If you give me any of your pubkey, I will extract 1 bit and give you back new pubkey
You can test yourself
My given pubkey by extract 1 bit
You will substract you key, , multiply by xxxxxx,
You will see new pubkey back at first pubkey
You repeats unlimited counts
Always you backed at 1st pubkey
Mean 1 bit loop never let you move anywhere

Tried to build X pubkey 135 using GX as started point, done the calculations manually for the whole 64byts, GX * I to get first 4bits of the pubkey, then i*16 (±31) * GX to get second 4bit .....
After ending with X1 wich is egal to X extended to 500±bits then (X1/64**16)/GX = exactly GX/X
So key that should be explored is the ±31 or maybe should be reduced to ±16 to get hex value from 0 to f

nice try.

my result is (python with ice256):

[27,535] 0.00% S: 307492.2 p/s, E: 13:26:34, TE: 24d 17:28:25, ETA: 1596914983724989361460084736y 8m 6d 13:32:48

interesting. 27k iteration, with 24days, with 23m each reduce hugiiliard years. (was 176.... at start)

[Kermits Froggy]

Where can I rent 500 GPUs for 3 months for this puzzle? Don't suggest providers like vast or clore or salad. I am interested in private deals only. Will pay in BTC or USDT.