Bitcoin puzzle transaction ~32 BTC prize to who solves it

[nomachine]

Congrats if Alberto Won. Clearly he deserved it, along with Nomachine Wanderingidkphotopsia too

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

Barely caught it myself. I guess this confirms that anything under 90 or 100 is a waste of time.
Thank you for the experiment, brazilian man.

Thank you to everyone that participated 🙏

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

[lmajowka]

Congrats if Alberto Won. Clearly he deserved it, along with Nomachine Wanderingidkphotopsia too

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

Barely caught it myself. I guess this confirms that anything under 90 or 100 is a waste of time.
Thank you for the experiment, brazilian man.

Thank you to everyone that participated 🙏

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

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

[WanderingPhilospher]

Congrats if Alberto Won. Clearly he deserved it, along with Nomachine Wanderingidkphotopsia too

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

Barely caught it myself. I guess this confirms that anything under 90 or 100 is a waste of time.
Thank you for the experiment, brazilian man.

Thank you to everyone that participated 🙏

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

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

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.

[kTimesG]

I also get that error many times, you need to keep increasing the Fee, this need to be done automatically, manually is almost impossible to send a TX.

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

Code:

010000000120e57c9717271536b9623703c14ed29b40c98c3c28f2667935f3d63897fae33e000000006a47304402201af96f3e52586885a5d14bbeb6d9a2951c7eabfbb7d8ab8a41cd3d2574976b78022020496a09878cf87704e47617731f551f201f9364c6cb4b904b48fd5e3ff3dd570121029fd3d2479a37f40d03975cb51ce0fa18cbb709cc46b47caeaa1722cfd3683583ffffffff0138840700000000001976a9148f4da084ec14ed710b96b6a086bbeb06d571faf988ac00000000

Code:

ver     01000000
txins   01 20e57c9717271536b9623703c14ed29b40c98c3c28f2667935f3d63897fae33e 00000000
SIG     6b 48 30 45
r       02 21 00963de23d2d3057f45927956f354384ba23a502b9574f100151121d356fa826a4
s       02 20 51b0ee4f84be544ffe8e2f9c31e9d2536554d8901f49c45771f42563ce34e341
PUB.X   01 21 029fd3d2479a37f40d03975cb51ce0fa18cbb709cc46b47caeaa1722cfd3683583
seq     ffffffff
out #   01
value   98fd050000000000
script  19 76a9148f4da084ec14ed710b96b6a086bbeb06d571faf988ac
lock    00000000

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.

[nomachine]

I will join and create my transaction with 6.6 BTC fees 

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

[albert0bsd]

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 ?

Yes you get it right, that is what actually happened

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

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.

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 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.

[k3ntINA]

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.

[albert0bsd]

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.

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

Code:

#Current function
def broadcast_transaction(raw_tx):
    try:
        url = ""
        if networkname=="bitcoin":
            url = "https://mempool.space/api/tx"
        elif networkname=="testnet":
            url = "https://mempool.space/testnet/api/tx"
        else:
            print("Unknow network")
            exit()
        response = requests.post(url, data=raw_tx)
        return response.text
    except requests.exceptions.RequestException as e:
        print(f"error {str(e)}")
        return ""

#Next is just an example, not the actual code.

networkname= 'bitcoin'
RAWTX = "010000000120e57c9717271536b9623703c14ed29b40c98c3c28f2667935f3d63897fae33e000000006a473044022068357d38b55b987e139ce069de456cb399b04f37861879bb7e425ef84b11816a0220425c3fb1c6fa90ca1d7ab6971375a94d62e36a49041d7cfda338d51f4169a08e0121029fd3d2479a37f40d03975cb51ce0fa18cbb709cc46b47caeaa1722cfd3683583ffffffff011821070000000000160014c0f3278346024832e71d25a24d5ae4b73885f85d00000000"
value = broadcast_transaction(RAWTX)
#Need to evaluate value to check if the TX was successful or not

[wilspen]

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.

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

Code:

#Current function
def broadcast_transaction(raw_tx):
    try:
        url = ""
        if networkname=="bitcoin":
            url = "https://mempool.space/api/tx"
        elif networkname=="testnet":
            url = "https://mempool.space/testnet/api/tx"
        else:
            print("Unknow network")
            exit()
        response = requests.post(url, data=raw_tx)
        return response.text
    except requests.exceptions.RequestException as e:
        print(f"error {str(e)}")
        return ""

#Next is just an example, not the actual code.

networkname= 'bitcoin'
RAWTX = "010000000120e57c9717271536b9623703c14ed29b40c98c3c28f2667935f3d63897fae33e000000006a473044022068357d38b55b987e139ce069de456cb399b04f37861879bb7e425ef84b11816a0220425c3fb1c6fa90ca1d7ab6971375a94d62e36a49041d7cfda338d51f4169a08e0121029fd3d2479a37f40d03975cb51ce0fa18cbb709cc46b47caeaa1722cfd3683583ffffffff011821070000000000160014c0f3278346024832e71d25a24d5ae4b73885f85d00000000"
value = broadcast_transaction(RAWTX)
#Need to evaluate value to check if the TX was successful or not

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?

[lmajowka]

Congrats if Alberto Won. Clearly he deserved it, along with Nomachine Wanderingidkphotopsia too

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

Barely caught it myself. I guess this confirms that anything under 90 or 100 is a waste of time.
Thank you for the experiment, brazilian man.

Thank you to everyone that participated 🙏

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

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

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.

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

[Akito S. M. Hosana]

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?

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

[nomachine]

There's an infinite free relay problem. You can keep broadcasting "high feerate" and "high fee" sets of transactions that replace each other, reusing the same fees and alternating which RBF rules you use.

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

[k3ntINA]

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

[jacky19790729]

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.
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

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)

[kTimesG]

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.

[Akito S. M. Hosana]

There's an infinite free relay problem. You can keep broadcasting "high feerate" and "high fee" sets of transactions that replace each other, reusing the same fees and alternating which RBF rules you use.

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

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

Do any of them even look at this topic here? 

[pbies]

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.

If this is possible with puzzle 66 address, then any address with tx in mempool is possible to be taken. Just the range is a little bigger but still computing the pvk should be the same easy as is for puzzle 66.

Then all BTC is in danger. You may want to try steal any other tx in mempool when there is pubkey available.

[AlanJohnson]

If this is possible with puzzle 66 address, then any address with tx in mempool is possible to be taken. Just the range is a little bigger but still computing the pvk should be the same easy as is for puzzle 66.

Then all BTC is in danger. You may want to try steal any other tx in mempool when there is pubkey available.

No. 

Properly generated bitcoin private key is insanely hard to crack  (it's 256 bit). Whole bitcoin strength is based on a fact that cracking 256bit is generally considered as impossible.

This can change when quantum machines will be introduced but currently you will not crack it even having PK available.

[nomachine]

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.
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

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)

They've made opt-in Replace-By-Fee (RBF) the default in Electrum version 4.4.0. If you want to use the old version without this feature by default, you can install version 4.3.0 using the following steps:


git clone https://github.com/spesmilo/electrum.git
cd electrum/
git checkout 4.3.0
pip3 install -r contrib/deterministic-build/requirements.txt
pip3 install .

You can use old version of Electrum but every transaction will automatically have RBF enabled on the node.
Only option is to change node in Electrum to your own full-RBF-disabled node.
And mine in secret this transaction.

However, once the transaction is broadcasted using any (API) method, it is at risk of being replaced.

Even if you share it privately with a third-party miner, that miner could still replace it..

[Gord0nFreeman]

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.
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

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)

They've made opt-in Replace-By-Fee (RBF) the default in Electrum version 4.4.0. If you want to use the old version without this feature by default, you can install version 4.3.0 using the following steps:


git clone https://github.com/spesmilo/electrum.git
cd electrum/
git checkout 4.3.0
pip3 install -r contrib/deterministic-build/requirements.txt
pip3 install .

You can use old version of Electrum but every transaction will automatically have RBF enabled on the node.
Only option is to change node in Electrum to your own full-RBF-disabled node.
And mine in secret this transaction.

However, once the transaction is broadcasted using any (API) method, it is at risk of being replaced.

Even if you share it privately with a third-party miner, that miner could still replace it..

I reached out to major mining pools, and they told me they can't confirm a transaction without it going through the mempool! The pool operators will take the entire reward for themselves, they’ve known about this for a while and are just waiting for it! I don’t even know what to do in this situation... It's frustrating.