Topic: Bitcoin puzzle transaction ~32 BTC prize to who solves it - page 45. (Read 215479 times)

So,  bitcoin-devs can change RBF (BIP 125) rules that this scenario cannot happen?

Do any of them even look at this topic here? 

The question is why didn't the bot work as expected, ideally the experiment should have resulted in all the BTC being burned into the fee (or at least a lot more TX than 3 or 4).

It seems the mempool rejects some TX even if the fee is substantially higher. There's something alberto does not tell us, or he was just very lucky. Or maybe the mempool push TX api was the secret sauce that worked.

Some ideas:
- spam the mempool with multiple TX with different output addresses and fees
- broadcast the TX to multiple destinations

And I don't think miners are idiots. Why would they help some random guy for 10 or 20 or 50%, when they can definitely
play the game on their own?

It took TWO seconds to crack the private key. Another fraction of a second to create the new raw TX with higher fee. But the TX pushing failed because of some mempool rules, that was the weird part. Anyway, it's not a matter of minutes here. So any miner can run a bot, do the cracking themselves, and include it in their own mined block no matter what happened in the mempool.

With zero fees. The miners may also reject TXs that try to increase the fee from other people.

After this experiment, I realized that the wallet  software "Electrum"  cannot grab the BTC of #66

we must  create own RawTX  (raw_hex)

use API broadcasts to blockchain

response = requests.post(
    'https://blockchain.info/pushtx',
    data={'tx': raw_tx}
)
print(response.text)

I don't know, maybe I'm wrong, but what I noticed is that your transaction was not broadcast from the Mempool route. I think you know a way.
https://www.talkimg.com/images/2024/07/21/4sa2H.gif

The history here has two networks, one is the main one and the other is the main Mempool route, the transaction was not confirmed on the Mempool route, although it was sent earlier, but it was not approved, and maybe the Mempool policy behaved like this. but your transaction did not pass through the Mempol route, am I wrong? ?


https://blockchair.com/bitcoin/address/197kFKvMHoRJPXktc8xJwMjeTuE9xijBQ

https://gist.github.com/glozow/797bb412868ce959dcd0a2981322fd2a

Nothing is safe anymore after this experiment. Seconds are at stake here. We are doomed.

I have a youtube channel, me and the subscribers (Are searching solo), But we do plan to have a pool some day

Alberto, there is a tool on the Binance website that allows you to pay a higher fee and have the transaction mined quickly, doing this transaction through Binance runs the risk of losing the BTC too, or it's the same, regardless of the place, it would only be safe directly with a miner?

What are you talking about? All TX pass thought mempool (Unless you mine the block)

What I did

1.- retrieve the public key from the mempool transaction (https://mempool.space/docs/api/rest#get-address-transactions-mempool)
2.- get the privatekey with keyhunt (bsgsd daemon https://github.com/albertobsd/keyhunt/blob/main/BSGSD.md )
3.- create a new TX with the UTXO (https://bitcoinlib.readthedocs.io/en/latest/  https://github.com/1200wd/bitcoinlib/blob/master/examples/transactions.py )
4.- broadcast the TX withthe mempool.space API  ( https://mempool.space/docs/api/rest#post-transaction )

All previous point were full automated with python

Some considerations:
2.- I scan from 0x1 to 0x3ffffffffffffffff to avoid previous mistakes of private keys in lower ranges, so It took me twice the amount of time needed to crack the privatekey (It was less than a minute)

4.- I should add some other API provider to broadcast transactions just to add redundancy

The code for broadcast in python using requests

Alberto, you did not broadcast the transaction in Mempool. Can you explain to us what you did? Although your transaction was sent later on the main network (not through Mempool), it was confirmed.

Yes you get it right, that is what actually happened


You welcome, lets to document this experiment a little bit just to keep the record for others:

Time UTC - 6

Block 853085 - 2024-07-20 12:35:12
Block 853086 - 2024-07-20 12:47:36 

There was a space of 12 minutes between previous block and this challenge block


Your original TX was 5 sat/vB with RBF disabled.



And here some of the Replacements:

13 sat/vB
First replacement listed was mine, (But remember not all accepted TX appear on this page, I already did some test and many Accepted TX disappear from this page)



Another One 29 sat/vB



44 sat/vB


52 sat/vB


64 sat/vB


77 sat/vB


93 sat/vB


111 sat/vB


135 sat/vB


Points to consider
- This was just luck, all depends of miner rules in update their block with new information or not
- No always higher bidder wins.
- Any listed transaction may had the possibility to win.


I wasn't aware of the first two, And actually my script scan from 1 to 3f.......... because i wasn't sure if you fixed you code or not (I don't want any surprise for this test)

The only robust  way to withdraw is to mine a block without broadcast the transaction before the block is mined, but this is difficult to do alone, maybe some miner should offer that option but there is no way to trust in a miner a weak public key under 90 bits.

This is exactly what will happen. Someone will pay a fee of 5 BTC in order to earn 1.6 BTC. 

I did increase the fees via script... One of my TX examples:


this has a fee of 100.000 (well above your winning TX) and it wasn't accepted by the mempool because of "mempool-txn-conflict". So something else happened, or you used some other trick when you broadcast your TX.

There are already strategies in place. No worries.
Also, are you searching for 66, solo, or any pools?

I hope to run a test, involving the same community, hopefully in the upcoming week...more to come.

First 2 were a disaster I had a bug in my code so the wallets had 62 instead of 66 bits. Luckily, no one was able to RBF me and the blocks came really fast. I am glad that this 3rd time worked. Now we need to work on robust withdrawl strategies for the hunters finding 66 and above

I wasn't even near the computer when this was happening, but I see that one of my RBFs passed.



Thank you for your patience. Someone wouldn't have the patience to do this three times.

Thank you Alberto!!!! I will mention in my next videos, my subscribers will go crazy

the same fucking problem i had that it says that the funds are 0 thats why i wasn't be able to broadcast a fooking new transaction.

but the real question is and moral of the story: Is puzzle 66 safe? From what i've seen yes. Because the attacker should be aware that he should broadcast a new transaction with higher fee multiple times for a chance for the actual transaction to be replaced.

So, although RBF was turned off in the transaction here, did the miner ignore it and did someone else increase the fee and provide a transaction?
Did I get right ?

As expected Congrats @albert0bsd

My noob bot struggling to see at least balance <= 0 and stuck here..