Bitcoin puzzle transaction ~32 BTC prize to who solves it

[SimonNeedsBitcoin]

How do you know the winner is transferring and broadcasting the fund? Do you get the public key immediately after the winner broadcast the transation? Does this take time?

Yes. In about 10-20 seconds you will be left with nothing.

It takes less than 2 seconds to break the private key of Puzzle 71 (once the initial TX is in the mempool), create the TX, and broadcast it, and to get it accepted by any miner.

The principle behind the puzzle bot can be explained more simply:

The bot checks a Bitcoin address for incoming transactions using a Python script.

If a transaction is found, it extracts the public key from the scriptsig field in the transaction input.

Example one-line Python command for puzzle 71:

Code:

python3 -c "import requests; import sys; address = sys.argv[1]; url = f'https://mempool.space/api/address/{address}/txs/chain'; r = requests.get(url); txs = r.json(); pubkey = next((vin['scriptsig'][-66:] for tx in txs for vin in tx['vin'] if 'scriptsig' in vin), None); print(f'Public key for address {address}: {pubkey}' if pubkey else 'Public key not found');" 1PWo3JeB9jrGwfHDNpdGK54CRas7fsVzXU

If the public key is found, it will appear like this:

Public key for address 197kFKvMHoRJPXktc8xJwMjeTuE9xijBQ: 029fd3d2479a37f40d03975cb51ce0fa18cbb709cc46b47caeaa1722cfd3683583

If not, it will return:

Public key not found

You can manually press Enter repeatedly until the public key appears.

Alternatively, you can automate it with a Python script that checks every 5 seconds indefinitely.

The public key will appear as soon as someone broadcasts a transaction from that address.

Faster Execution with a Local Node

If you're running a local Bitcoin node (e.g., with Umbrel), you can query your own mempool instead of an external API:

Code:

url = f'http://mempool.localhost/api/address/{address}/txs/chain'

This reduces latency and speeds up detection.

Once the public key is obtained, Kangaroo is used to derive the private key, typically in 2-3 seconds.

The script then replaces the original transaction in the mempool before it gets confirmed.

Example:

bitcoin-cli createrawtransaction 'INPUTS' 'OUTPUTS'
bitcoin-cli signrawtransactionwithkey 'HEX' '["PRIVATE_KEY"]'
bitcoin-cli sendrawtransaction 'SIGNED_HEX'

No Rate Limits: Local mempool API is faster and unrestricted.

Real-Time Detection: Sees transactions as soon as they enter the mempool.

Thank you for your detailed explanation. It seems that this kind of robot can really steal the bonus very quickly. Although I don’t believe it can be done in 2 seconds, it seems that it can be done within a minute or even tens of seconds. Broadcasting in a public mining pool is indeed very dangerous.

[Igor_cherkassy]

Can anyone share any key to 1PWo3JeB9jr.... Thanks.

[mahmood1356]

Can anyone share any key to 1PWo3JeB9jr.... Thanks.

649a103b78b3e74856

[kTimesG]

It seems that this kind of robot can really steal the bonus very quickly. Although I don’t believe it can be done in 2 seconds, it seems that it can be done within a minute or even tens of seconds. Broadcasting in a public mining pool is indeed very dangerous.

Good, progress.

Now, let's take it one step forward.

Having the pubKey of Puzzle #71 means solving the ECDLP in a 70-bits interval.

Algorithms such as BSGS or Kangaroo will thus require around 2**36 EC group operations, when starting from a zero setup.

Let's take RCKangaroo as a base reference (just for example sake, it is NOT an optimized solver).

With that demo program, an RTX 4090 can do around 8 Gop/s EC (group operations per second).

So, the ECDLP will be broken in around 8.5 seconds.

Let's now actually take it one step further and solve it much faster than that.

If you investigate why the ECDLP of a 70-bit interval is solved in only 2 * 2**35 steps, you will notice that 2**35 of those steps start off from a known private key. So the solving equation can be expressed like this:

intervalSize = numRequiredOpsA * numRequiredOpsB
(example: 2**70 = 2**35 * 2**35)

where you can twiggle around with the right-hand numbers.

Mathematically, the optimal (minimal) effort occurs when those two numbers have the same magnitude, because that is when the sum of the numbers is at a minimum.

However, if one wants to accelerate the solving by trading off the initial effort, we can rewrite things like this:

intervalSize = bigNumberA * smallNumberB
(example: 2**70 = 2**70 * 1)

In this example, somebody precomputes and stores all the keys of the interval, and when the public key becomes available, then the solving side only takes one step (a lookup).

D. J. Bernstein wrote a great paper on how we can take advantage of this in the ECDLP context. It turns out, that we can do something like this if we want:

bigNumberA = 2**40
smallNumberB = 2**30

In this example, we can spend a decent amount of time working out and storing data for whatever 2**40 private keys that we wish. Once we have this data prepared, when the public key is revealed, we'd only need 2**30 steps to find the associated private key.

Now, let's revisit the solve times, on a RTX 4090 (just for fun):

Precomputing time: 2**40 steps = 138 seconds
Solving time: 2**30 steps = 0.13 seconds

Maybe this should make people understand why puzzles 71 to 100+ are basically sitting ducks, and can be solved in a matter of minutes (in total).

[MrGPBit]

Can anyone share any key to 1PWo3JeB9jr.... Thanks.

649a103b78b3e74856

Public Addr: 1PWo3JeB9jRLz2NjTHsZ8uTBnqcjnu66Ak

Unfortunately, the letter R is capitalized and does not match the destination address

[viljy]

~
D. J. Bernstein wrote a great paper on how we can take advantage of this in the ECDLP context. It turns out, that we can do something like this if we want:

bigNumberA = 2**40
smallNumberB = 2**30

In this example, we can spend a decent amount of time working out and storing data for whatever 2**40 private keys that we wish. Once we have this data prepared, when the public key is revealed, we'd only need 2**30 steps to find the associated private key.

Now, let's revisit the solve times, on a RTX 4090 (just for fun):

Precomputing time: 2**40 steps = 138 seconds
Solving time: 2**30 steps = 0.13 seconds

Maybe this should make people understand why puzzles 71 to 100+ are basically sitting ducks, and can be solved in a matter of minutes (in total).

An interesting idea. And it's actually so simple, and very clever. I sometimes read threads about the puzzle, I even searched for private keys before, until I saw that you can hardly do without large financial costs.


P.S. As for the 71 range, I don't see a bot problem at all if the person who found the key uses Mara so that the transaction doesn't end up in the mempool.

[uvindele]

Can anyone share any key to 1PWo3JeB9jr.... Thanks.

7F92587DD9BD019205

[Tony8989]

Mara is a tool designed to quickly replace or front-run unconfirmed transactions by broadcasting competing ones. For the attacker, it’s effective and “safe” to use. For the victim, it means a real risk of losing funds if their transaction gets replaced before confirmation

basically Mara is one of several tools designed to do the same thing: quickly replace or front-run unconfirmed Bitcoin transactions by broadcasting competing transactions with higher fees.

What makes Mara notable is it’s often optimized for speed and automation, especially in the context of puzzle key cracking and mempool monitoring.

But fundamentally, it uses Bitcoin’s standard Replace-By-Fee (RBF) or mempool replacement rules—just like any other mempool??

[BlackAKAAngel]

my  BOT  its foolauto  


Monitor the address for new transactions. evry two secund refresh
 When a new transaction appears, it will get the txid and the amount
 it  will then extract the public key
 it will run RCKangaroo to find the private key
 As soon as the private key is found, it will
 Get the recommended transaction fee
 Create a new transaction to send the funds to your destination address, including the calculated fee.
 Sign the transaction
 Print the raw transaction hex to the console
 
and i testet work well

[Jorge54PT]

Mara is a tool designed to quickly replace or front-run unconfirmed transactions by broadcasting competing ones. For the attacker, it’s effective and “safe” to use. For the victim, it means a real risk of losing funds if their transaction gets replaced before confirmation

basically Mara is one of several tools designed to do the same thing: quickly replace or front-run unconfirmed Bitcoin transactions by broadcasting competing transactions with higher fees.

What makes Mara notable is it’s often optimized for speed and automation, especially in the context of puzzle key cracking and mempool monitoring.

But fundamentally, it uses Bitcoin’s standard Replace-By-Fee (RBF) or mempool replacement rules—just like any other mempool??

Mara doesn't publish the public key. Without it, no bot will notice any ID txid , public key, or anything else. When the origin address is 0, the all balance it's already in my new wallet then in the mempool my transaction appears saying: Public key not available or not published  something like that.
in short: bots are useless with Mara

https://www.binance.com/en/square/post/22423542983737

[SimonNeedsBitcoin]

my  BOT  its foolauto  


Monitor the address for new transactions. evry two secund refresh
 When a new transaction appears, it will get the txid and the amount
 it  will then extract the public key
 it will run RCKangaroo to find the private key
 As soon as the private key is found, it will
 Get the recommended transaction fee
 Create a new transaction to send the funds to your destination address, including the calculated fee.
 Sign the transaction
 Print the raw transaction hex to the console
 
and i testet work well

Does anyone else here have objections of designing such a robot? Is this unethical behavior commonplace?

[Cricktor]

My viewpoint is that bots are part of the game and challenge. Bots use publicly available data to compete and I don't really see anything unethical with that.

When there are developed public tools which can find a private key much faster once the public key is publicly exposed, then anyone who participates in finding puzzle solutions has to cope with that.

You may perceive it as unfair because it's hard and costly to find the solution for #71^{or any remaining below 100ish} as long as the public key is yet unknown. The puzzle creator gave his coins to be redeemed by anyone who can find a private key. Week entropy private keys are what they are: no safe protection for coins they control once the public key is exposed (and the weak entropy is known). If exposure of the public key makes the coins very vulnerable, then this is it exactly. Deal with it!

I may have referred in the past of such bots as stealer bots. After some thinking about it and my viewpoint presented above, I wouldn't declare it that way anymore. It's in my opinion no stealing.

YMMV, I'm genuinely interested how others see it. Please, try to explain if your opinion differs. I might be wrong with my own opinion and if so, I'd like to learn why!

[Tony8989]

ok so what is the solution i mean now the hard part is to get the bitcoin safe to your wallet, puzzle 71 is hard but not hard but the hard part is to send the found to your wallet
 lots of guys talk about mara but feel like mara is bots himself, and what about puzzle 67,66,65 ect found where safe send it to the wallet with not problem

[benjaniah]

ok so what is the solution i mean now the hard part is to get the bitcoin safe to your wallet, puzzle 71 is hard but not hard but the hard part is to send the found to your wallet
 lots of guys talk about mara but feel like mara is bots himself, and what about puzzle 67,66,65 ect found where safe send it to the wallet with not problem

You got it backwards, bro.
The hard part is finding the private key to the puzzle wallet address.
The easy part is creating the transaction that spends the puzzle UTXO's to your own wallet, and submitting the tx to Mara Slipstream.

[Tony8989]

Let’s get you verified
Select your residency and follow the steps
Residence
United Kingdom
Our service is not available at this time
Binance is currently reorganising its activities in the UK. Our services will be available soon. Stay tuned!

[Cricktor]

I wonder if other mining pools will implement something similar and public like https://slipstream.mara.com? Because regarding average block fees over time, Mara does have a significant edge compared to other mining pools, while only having around 5% of total network hash power.

See e.g. for past 1y https://mempool.space/graphs/mining/pools#1y where Mara blocks generate them on average a bit more than +6% additional transaction fees while all other mining pools have lower (below par, negative percentage) than naive mempool content transactions fees (the baseline of mempool.space is likely what their mempool sees as fees in all transactions they are aware of).

I'm pretty sure the better fee performance of Mara is attributed mostly to their public and easy accessible Slipstream service. It's at least double more expensive by default and offers also opportunities to get non-standard transactions confirmed, too. And of course the hidden non-public mempool of Slipstream is mandatory to (so far) safely redeem low entropy puzzles by not exposing a public key to the public while the transactions waits to be confirmed in a block.

[ExernalVN]

 but once you have the public key you can get the private key in seconds.

Tell me please what algorithm should be used if the range for the private key is known and the public key is known?

[sxiclub]

my  BOT  its foolauto  


Monitor the address for new transactions. evry two secund refresh
 When a new transaction appears, it will get the txid and the amount
 it  will then extract the public key
 it will run RCKangaroo to find the private key
 As soon as the private key is found, it will
 Get the recommended transaction fee
 Create a new transaction to send the funds to your destination address, including the calculated fee.
 Sign the transaction
 Print the raw transaction hex to the console
 
and i testet work well

Does anyone else here have objections of designing such a robot? Is this unethical behavior commonplace?

It's unethical and very common. To me, it's the same as a thief waiting at a bank door for someone who's gone to make a cash withdrawal, only without the violence involved. Perhaps we should accept what another user said; it's part of the game in this virtual, anonymous world.

[kTimesG]

It's unethical and very common. To me, it's the same as a thief waiting at a bank door for someone who's gone to make a cash withdrawal, only without the violence involved. Perhaps we should accept what another user said; it's part of the game in this virtual, anonymous world.

Except that the someone making a cash withdrawal did it with a mask over their head and an AK47, if you know what I mean. There's absolutely nothing that entitled them to get the funds in the first place. If spending vast amounts of effort and money just to recover back a third of it (because IQ was too low before even attempting) is some sort of justification of cashing in some reward which was never under your name to begin with, let me bring you back to the real world: nobody will give a shit about personal dramas caused by stupidity.

[Kelvin555]

It's unethical and very common.

It's ethical.... whatever those bots are doing to low entropy puzzles is what RC is doing to puzzles over 115 bits with his RCKangaroo.

From outgoing transaction -> extract public key -> from public key find private key -> create and sign another transaction with the private key.

It does not matter who created the first outgoing transaction in the first place.