Bitcoin puzzle transaction ~32 BTC prize to who solves it

[fantom06]

Simulation 10000: Sequential = 132246 | Prefix = 122826

=== FINAL RESULTS ===
Wins:
Sequential: 321 (Average Win Margin: 48.81%)
Prefix: 9033 (Average Win Margin: 3.21%)
Ties: 646

Total Checks:
Sequential: 5,216,987,277
Prefix: 5,224,672,888

[White hat hacker]

Can you tell me the difference between the prefix method and the random method? At the end of the day, the code is still random—there’s no magic to it and it's not surprising..


It's better to use both random and sequencial.

[Bram24732]

It not complicated. Nor is it a bias. Those are actual numbers out of your script.
On average, both methods require the same number of steps to reach a solution.

Noo,

If we take these metrics into account, it only means that, approximately within that key range, the prefix method achieved a higher success rate, which is highly significant.

dividing keys(avg) by wins, you'd determine the average success rate.

Code:

keys(avg)/wins  =  success_rate(avg)

I'm not sure what's unclear.
Over 10000 attempts, sequential method had to make 5,216,987,277 checks before finding 10000 solutions
Over 10000 attempts, prefix method had to make 5,224,672,888 checks before finding 10000 solutions
The average number of checks is similar for both methods ?

[fantom06]

=== Configuration ===
Total numbers: 1,048,576
Block size: 4,096
Prefix: 4 characters (16^4 combinations)
Simulations: 10000

=== FINAL RESULTS ===
Wins:
Sequential: 343 (Average Win Margin: 51.00%)
Prefix: 9054 (Average Win Margin: 3.23%)
Ties: 603

Total Checks:
Sequential: 5,283,346,262
Prefix: 5,306,416,800




=== Configuration ===
Total numbers: 2,097,152
Block size: 4,096
Prefix: 3 characters (16^3 combinations)
Simulations: 10000

=== FINAL RESULTS ===
Wins:
Sequential: 3736 (Average Win Margin: 42.57%)
Prefix: 6244 (Average Win Margin: 36.55%)
Ties: 20

Total Checks:
Sequential: 10,472,126,509
Prefix: 10,548,477,557


Simulation 10000:

Range= 0x7783106664cade9ef313deb9c088f05841f3c274a4661258f96e00da053d8d4e:0x7783106664cade9ef313deb9c088f05841f3c274a4661258f96e00da053f13ee

Target= 4f27af87ce608fbb0a02b8c601ec9e8a9e44db86
Checks: Sequential = 66881 | Prefix = 41959

=== FINAL RESULTS ===
Wins:
Sequential: 4085
Prefix: 5484
Ties: 431

[moderator's note: consecutive posts merged]

[zahid888]

Hahaha, take it easy... It’s not that simple... But... Every member in this topic will get 0.2 BTC—if they have a BTC address in their signature. Satisfied? 

Are you talking about that key?

Code:

KyDi5tDzUCEN5bCRZhiS5sEGMpmcRZdpAhmWLRfMmutGmPHtjVob
KyDi5tFNbmN45bCRZhiS5sEGMpmcRZdpAhmWLRfMmutGmPHtjVob
KyDi5tJzYm5M5bCRZhiS5sEGMpmcRZdpAhmWLRfMmutGmPHtjVob
KzDiBk1GeGqp5bCRZhiS5sEGMpmcRZdpAhmWLRfMmutGmPHtjVob
KzDiBk2nLZCk5bCRZhiS5sEGMpmcRZdpAhmWLRfMmutGmPHtjVob
KzDiBk377UHr5bCRZhiS5sEGMpmcRZdpAhmWLRfMmutGmPHtjVob
L2Die4KeEMng5bCRZhiS5sEGMpmcRZdpAhmWLRfMmutGmPHtjVob
L3DiBgEqot9K5bCRZhiS5sEGMpmcRZdpAhmWLRfMmutGmPHtjVob

That’s probably a scam. I’ve bunch of WIFs with partial matches in sequence, be careful not to waste your time there.



For those who think searching for WIF has some magical twist—let me tell you, it's much slower compared to generating an address directly from a private key (hex, bytes or dec).

@nomachine, maybe let the curious minds DM you directly -: this thread’s starting to feel like a rerun marathon. Let’s save the scrolls for fresh stuff!

-- Sim results

If you sum the number of checks over 10k simulations you get this :

Code:

=== FINAL RESULTS ===
Sequential: 495816995
Prefix: 496059807

WHICH IS ALMOST 50-50!

And maybe I have conducted the most experiments on prefixes, whether it be in the form of base58 or hash160.
Through these experiments, I have consistently encountered a 50-50 probability of outcomes.

but the basic aspect has already been demonstrated, which was the probabilistic success rate.

Well done! But let’s be real—if we’re talking probabilities, I Still remember, how you got yourself stuck in this argument when you trying to defend someone. Your heroic moment, huh? Maybe now’s a good time to snap out of that mess and chase some actual probability breakthroughs.

=== Configuration ===
Total numbers: 2,097,152
Block size: 4,096
Prefix: 3 characters (16^3 combinations)
Simulations: 10000

=== FINAL RESULTS ===
Wins:
Sequential: 3736 (Average Win Margin: 42.57%)
Prefix: 6244 (Average Win Margin: 36.55%)
Ties: 20

Total Checks:
Sequential: 10,472,126,509
Prefix: 10,548,477,557

Bro demonstration is over now! lets reduce the talk in this forum that we can easily read important posts And thanks for searching all 10 digit seeds for me 

[nomachine]

Are you talking about that key?

Code:

KyDi5tDzUCEN5bCRZhiS5sEGMpmcRZdpAhmWLRfMmutGmPHtjVob
KyDi5tFNbmN45bCRZhiS5sEGMpmcRZdpAhmWLRfMmutGmPHtjVob
KyDi5tJzYm5M5bCRZhiS5sEGMpmcRZdpAhmWLRfMmutGmPHtjVob
KzDiBk1GeGqp5bCRZhiS5sEGMpmcRZdpAhmWLRfMmutGmPHtjVob
KzDiBk2nLZCk5bCRZhiS5sEGMpmcRZdpAhmWLRfMmutGmPHtjVob
KzDiBk377UHr5bCRZhiS5sEGMpmcRZdpAhmWLRfMmutGmPHtjVob
L2Die4KeEMng5bCRZhiS5sEGMpmcRZdpAhmWLRfMmutGmPHtjVob
L3DiBgEqot9K5bCRZhiS5sEGMpmcRZdpAhmWLRfMmutGmPHtjVob

That’s probably a scam. I’ve bunch of WIFs with partial matches in sequence, be careful not to waste your time there.

It's possible... but I have a match like '1PfNh5' in the address, for example, so I’m not sure what to think. The problem is that the range is huge—larger than life 

[kTimesG]

Your script has a problem. It's running all simulations on the same numbers (1 -> 100000) - You can see that line 17.

Oh no. This was a feature not a bug: "same initial conditions". Did you miss the AI response that clarifies everything?

I'm sorry, but I can only mock you now; your downfall is already too evident.

Let's make a bet, to find out who's right and who's wrong.

If I prove to you that I can find some arbitrary range distribution where the sequential method is better, with your exact code as it is, will you leave the forum forever? If not, I will. How's that for a bet?

Lol,   ,

I guess it was too risky for you?

Anyway, everyone knows you'll return again tomorrow and start again with the prefix probability dementia, like nothing ever happened. It's part of your routine here for a too long time.

[Akito S. M. Hosana]

I have a match like '1PfNh5' in the address, for example

I have up to "1Pf" at the most.  I can imagine how many millions of addresses need to be searched to find a significant match...

[fantom06]

Hahaha, take it easy... It’s not that simple... But... Every member in this topic will get 0.2 BTC—if they have a BTC address in their signature. Satisfied? 

Are you talking about that key?

Code:

KyDi5tDzUCEN5bCRZhiS5sEGMpmcRZdpAhmWLRfMmutGmPHtjVob
KyDi5tFNbmN45bCRZhiS5sEGMpmcRZdpAhmWLRfMmutGmPHtjVob
KyDi5tJzYm5M5bCRZhiS5sEGMpmcRZdpAhmWLRfMmutGmPHtjVob
KzDiBk1GeGqp5bCRZhiS5sEGMpmcRZdpAhmWLRfMmutGmPHtjVob
KzDiBk2nLZCk5bCRZhiS5sEGMpmcRZdpAhmWLRfMmutGmPHtjVob
KzDiBk377UHr5bCRZhiS5sEGMpmcRZdpAhmWLRfMmutGmPHtjVob
L2Die4KeEMng5bCRZhiS5sEGMpmcRZdpAhmWLRfMmutGmPHtjVob
L3DiBgEqot9K5bCRZhiS5sEGMpmcRZdpAhmWLRfMmutGmPHtjVob

That’s probably a scam. I’ve bunch of WIFs with partial matches in sequence, be careful not to waste your time there.



For those who think searching for WIF has some magical twist—let me tell you, it's much slower compared to generating an address directly from a private key (hex, bytes or dec).

@nomachine, maybe let the curious minds DM you directly -: this thread’s starting to feel like a rerun marathon. Let’s save the scrolls for fresh stuff!

-- Sim results

If you sum the number of checks over 10k simulations you get this :

Code:

=== FINAL RESULTS ===
Sequential: 495816995
Prefix: 496059807

WHICH IS ALMOST 50-50!

And maybe I have conducted the most experiments on prefixes, whether it be in the form of base58 or hash160.
Through these experiments, I have consistently encountered a 50-50 probability of outcomes.

but the basic aspect has already been demonstrated, which was the probabilistic success rate.

Well done! But let’s be real—if we’re talking probabilities, I Still remember, how you got yourself stuck in this argument when you trying to defend someone. Your heroic moment, huh? Maybe now’s a good time to snap out of that mess and chase some actual probability breakthroughs.

=== Configuration ===
Total numbers: 2,097,152
Block size: 4,096
Prefix: 3 characters (16^3 combinations)
Simulations: 10000

=== FINAL RESULTS ===
Wins:
Sequential: 3736 (Average Win Margin: 42.57%)
Prefix: 6244 (Average Win Margin: 36.55%)
Ties: 20

Total Checks:
Sequential: 10,472,126,509
Prefix: 10,548,477,557

Bro demonstration is over now! lets reduce the talk in this forum that we can easily read important posts And thanks for searching all 10 digit seeds for me 

I'm always happy to help! Contact me if you have any questions!

[fantom06]

Simulation 100000: Sequential = 47098 | Prefix = 75928

=== FINAL RESULTS ===
Wins:
Sequential: 40727
Prefix: 55067
Ties: 4206

[paulllex]

Hi guys,

In continuation to this thread: https://bitcointalk.org/index.php?topic=1305887.0

While playing around with my bot, I found out this mysterious transaction:

https://blockchain.info/tx/08389f34c98c606322740c0be6a7125d9860bb8d5cb182c02f98461e5fa6cd15

those 32.896 BTC were sent to multiple addresses, all the private keys of those addresses seem to be generated by some kind of formula.

For example:

Address 2:

KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU74sHUHy8S
1CUNEBjYrCn2y1SdiUMohaKUi4wpP326Lb
Biginteger PVK value: 3
Hex PVK value: 3

Address 3:

KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU76rnZwVdz
19ZewH8Kk1PDbSNdJ97FP4EiCjTRaZMZQA
Biginteger PVK value: 7
Hex PVK value: 7

Address 4:

KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU77MfhviY5
1EhqbyUMvvs7BfL8goY6qcPbD6YKfPqb7e
Biginteger PVK value: 8
Hex PVK value: 8

Address 5:

KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU7Dq8Au4Pv
1E6NuFjCi27W5zoXg8TRdcSRq84zJeBW3k
Biginteger PVK value: 21
Hex PVK value: 15

Address 6:

KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU7Tmu6qHxS
1PitScNLyp2HCygzadCh7FveTnfmpPbfp8
Biginteger PVK value: 49
Hex PVK value: 31

Address 7:

KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU7hDgvu64y
1McVt1vMtCC7yn5b9wgX1833yCcLXzueeC
Biginteger PVK value: 76
Hex PVK value: 4C

Address 8:

KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU8xvGK1zpm
1M92tSqNmQLYw33fuBvjmeadirh1ysMBxK
Biginteger PVK value: 224
Hex PVK value: E0

Address 9:

KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUB3vfDKcxZ
1CQFwcjw1dwhtkVWBttNLDtqL7ivBonGPV
Biginteger PVK value: 467
Hex PVK value: 1d3

Address 10:

KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUBTL67V6dE
1LeBZP5QCwwgXRtmVUvTVrraqPUokyLHqe
Biginteger PVK value: 514
Hex PVK value: 202

Address 11:

KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUGxXgtm63M
1PgQVLmst3Z314JrQn5TNiys8Hc38TcXJu
Biginteger PVK value: 1155
Hex PVK value: 483

Address 12:

KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUW5RtS2JN1
1DBaumZxUkM4qMQRt2LVWyFJq5kDtSZQot
Biginteger PVK value: 2683
Hex PVK value: a7b

Address 13:

KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUspniiQZds
1Pie8JkxBT6MGPz9Nvi3fsPkr2D8q3GBc1
Biginteger PVK value: 5216
Hex PVK value: 1460

Address 14:

KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFVfZyiN5iEG
1ErZWg5cFCe4Vw5BzgfzB74VNLaXEiEkhk
Biginteger PVK value: 10544
Hex PVK value: 2930

and so on...

until the addresses 50 (1MEzite4ReNuWaL5Ds17ePKt2dCxWEofwk) it was already cracked by someone.

Any ideas what's the formula behind the generation of these addresses?

Address 2, pvk decimal value: 3
Address 3, pvk decimal value: 7
Address 4, pvk decimal value: 8
Address 5, pvk decimal value: 21
Address 6, pvk decimal value: 49
Address 7, pvk decimal value: 76
Address 8, pvk decimal value: 224
Address 9, pvk decimal value: 467
Address 10, pvk decimal value: 514
Address 11, pvk decimal value: 1155
Address 12, pvk decimal value: 2683
Address 13, pvk decimal value: 5216
Address 14, pvk decimal value: 10544
Address 15 and after, pvk decimal value: ?

The prize would be ~32 BTC

EDIT: If you find the solution feel free to leave a tip 1DPUhjHvd2K4ZkycVHEJiN6wba79j5V1u3

It is impossible to deduce the private key from the address, that is what the Bitcoin white paper is about, that the possibility of doing that is almost zero, however, could Satoshi have left another route? Maybe he knew perfectly well that it was impossible so he kept his Bitcoin in a place where it is possible to enter knowing certain clues and that is also in the white paper, any ideas, about the vault??? satoshin@gmx.com

[kTimesG]

Can you at least read the thread so you don't talk about things that were resolved three centuries ago?

with their correct avg totals and all their requests:

Code:

=== FINAL RESULTS ===
Wins:
Sequential: 93
Prefix: 102
Ties: 5
Total Checks:
Sequential: 10311893
Prefix: 10599385
Average Success Rates:
Total Avg / Wins
Sequential(1 victory for each): 110880.57
Prefix(1 1 victory for each): 103915.54

I guess we're on our way to shit 10 pages of "why" after all. I thought the demonstration was over once the empirical tests converged to 50% to 50% operations.

This is exactly what I predicted will happen.

Are you sure about that? You'd just read the results wrong, ultimately. At which point your code is so specific, that it needs to go back to the general case. And so on.

Now, back to your code. In summary, you're testing which method finds the result FASTER using a methodology that is relevant for a chess tourney or sports gambling. In a game of chess, you either win or lose, but it doesn't matter how good the opponent played.

Basically you are dismissing altogether the amount of work being performed, it only matters to you who got first to the solution, which makes no sense - because you're not factoring in how MUCH it took to get there.

The margins of when sequential wins compensate for the fewer wins, and honestly I have no idea what's the basis of that formula you applied, or what exactly it represents.

But thanks for at least fixing up the distribution issue. Maybe next time your replies to serious issues are not AI + LOLs, otherwise I can't really take you seriously - I'm just reflecting your attitude, at the end of the day.

[kTimesG]

I already demonstrated that it's not 50/50 and that prefixes are the best method. I have to remind you that we all, at some point, make mistakes, just like you and your closed code, which, by the way, I was the only one who didn’t throw you to the sharks.

I guess we're on our way to shit 10 pages of "why" after all. I thought the demonstration was over once the empirical tests converged to 50% to 50% operations.

This is exactly what I predicted will happen.

Lol

Ok, mister "LOL". Let me LOL a little too:

You are computing in an absurd way that last comparison.

Let's say that the win rate is 1 for sequential and 999 for prefix.

And we have 50 million total ops for sequential and 50 million total ops for prefix.

That doesn't make prefix 999 times faster. Because you are including the amount of ops no matter if the seq or prefix won or lost, which makes no sense whatsoever. You're dividing by the number of wins, but with a total for both scenarios.

[kTimesG]

snip~

Lol, this is boring, looking for the five legs of the cat, you're just saying nonsense.

Non-sense? Of course. And it's obviously boring, high-lighting the factual errors on your fallacies can't be the truth, it's simply boredom. You're stepping in nicely into bib's shoes.

At this point, any rational person would ask you if you took your pills today, though. I won't do that, you obviously don't need any, you have your own made-up math reality going for you nicely!

1. Search

Code:

        seq_result = sequential_search(dataset, RANGE_SIZE, target_hash, order)
        pre_result = precise_search(dataset, RANGE_SIZE, PREFIX_LENGTH, target_hash, order)

2. Add to total ops

Code:

        # Suma de checks globales
        results["sequential"]["total_checks"] += seq_result["checks"]
        results["precise"]["total_checks"] += pre_result["checks"]

3. This is a chess game, so let's see who gets the trophy

Code:

        if seq_result["checks"] < pre_result["checks"]:
            results["sequential"]["wins"] += 1
        elif seq_result["checks"] > pre_result["checks"]:
            results["precise"]["wins"] += 1
        else:
            results["ties"] += 1

4. Show effective stats

Code:

        print(f"Checks: Sequential = {seq_result['checks']} | Prefix = {pre_result['checks']}")

5. Use some made up formula that doesn't really make sense with anything, since it mixes in total ops with the chess trophy counters.

Code:

    # Calcular avg success rate
    avg_success_rate_sequential = (results["sequential"]["total_checks"] / results["sequential"]["wins"]
                                   if results["sequential"]["wins"] > 0 else float('inf'))
    avg_success_rate_precise = (results["precise"]["total_checks"] / results["precise"]["wins"]
                                if results["precise"]["wins"] > 0 else float('inf'))

Golden.

[abdullahsoliman]

Guys, I've been silent for a long time, but you guys have been arguing for over 20 pages, and the person who understands is the one who avoids arguing in general. You've wasted 20 pages without any benefit, and both teams are right, and each has its justifications, theories, evidence, and orientations. For those who argue, there are moderators, and if there was something worth arguing about, you would have found responses. I hope we focus on what the thread was created for. Thank you for all your efforts, and my regards.

[kTimesG]

snip~

Code:

=== FINAL RESULTS ===
Wins:
Sequential: 181
Prefix: 296
Ties: 23
Total Checks:
Sequential: 24959280
Prefix: 24189089
Average Success Rates:
Total Avg / Wins
Sequential(1 victory for each): 137896.57
Prefix(1 1 victory for each): 81719.90

My brain's fried, let's ai:

There’s nothing syntactically “wrong” with this code, but there are a few logical and statistical issues in the way you’re comparing the two search methods:

1. You’re averaging “checks” only over wins

Code:

avg_success_rate_sequential = total_checks_sequential / wins_sequential

This gives you the average number of checks taken only in the cases where sequential_search “won”, ignoring all the other runs (losses and ties).

That means if one method rarely “wins,” you’ll divide by a very small number and get a deceptively large average.

Conversely, if it wins almost every time, you’ll be averaging only its best performances.

What you probably want instead is the average number of checks per trial, across all trials, regardless of whether it “won,” “lost,” or “tied” on that trial:

2. “Wins” as a performance metric is crude

You’re counting a “win” whenever method A uses strictly fewer checks than method B on a single trial. But that ignores how much better it was. A method that “wins” by 1 check a thousand times but “loses” by 10 checks just once will look like a bad runner‑up even though it’s dramatically faster on average.

Better alternatives:

Compare the distribution of checks (mean, median, percentiles) rather than just counting wins.

Compute the mean difference in checks per trial:

3. Ties are effectively ignored in your averages

You increment results["ties"], but then never use that count in any of your averages or analyses. If ties are frequent, you’re throwing away a lot of information.

[kTimesG]

snip~

Let it go, bro!... this is already boring.

Sorry, but you make it sound like "I already proved you whatever, let's move on".

But you are in a huge, humongous error.

Again: if I have 1 win with method A in 1000 simulations, with 50 million total ops.
And 999 wins with method B in 1000 simulations, with 50 million total ops.

Then on average, they both have the exact same performance:

50 mil ops / 1000 sim = 50 thousand ops / simulation.

Your formula, on the other hand, is absurd, showing that method A runs in 50 million ops / win, and method B runs in ~ 50000 ops / win, which is totally false. Method A ran 50 million ops for ALL the sims, not just for the win.

Get it now?

[btc11235]

Guys, I've been silent for a long time, but you guys have been arguing for over 20 pages, and the person who understands is the one who avoids arguing in general. You've wasted 20 pages without any benefit, and both teams are right, and each has its justifications, theories, evidence, and orientations. For those who argue, there are moderators, and if there was something worth arguing about, you would have found responses. I hope we focus on what the thread was created for. Thank you for all your efforts, and my regards.

I wholeheartedly agree.

...snip pages and pages worth of unproductive back-and-forth...

...snipping the latest round of back-and-forth...

Get it now?

No, he doesn't get what you're saying. And you don't get what he's trying to say either. And you're both just going around and around in circles. And if y'all haven't come to a consensus or mutual understanding by now, it's not going to happen... Please move this discussion elsewhere, or just give it up and agree to disagree, please and thank you.

[Akito S. M. Hosana]

Or does winning not matter?

It seems that the one who is the most boring wins here. 

[kTimesG]

Yeah man, let's end this argument.

You are right in all aspects, OK?

Let's simulate a simulation of two methods:

Code:

Checks   Wins
  A   B    A B
100 101    1 0
100 101    2 0
100 101    3 0
100  96    3 1

A's the winner here - 3 wins, who cares about costs. We're cracking Bitcoin keys on repeat mode after all, this makes sense.

Whoever says B is better - they are lying. Fuck averages. B's the loser here. 400 checks per win. Lame!

That's like, 3 times worse than A, which wins by a long shot: 133 checks / win!

Thank you for teaching us the holy grail of computing which method's the best. Yes, winning matters. In fact, all that matters is the winning and that's it.

Where do I sign up for my badge and cap?