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