lmajowka
Newbie
Offline
Activity: 8
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 20, 2024, 08:30:09 PM |
|
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. ![Grin](https://bitcointalk.org/Smileys/default/grin.gif) 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 ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) 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
Full Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 1120
Merit: 235
Shooters Shoot...
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 20, 2024, 08:59:56 PM |
|
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. ![Grin](https://bitcointalk.org/Smileys/default/grin.gif) 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 ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) 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
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 116
Merit: 24
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 20, 2024, 09:04:08 PM |
|
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: 010000000120e57c9717271536b9623703c14ed29b40c98c3c28f2667935f3d63897fae33e000000006a47304402201af96f3e52586885a5d14bbeb6d9a2951c7eabfbb7d8ab8a41cd3d2574976b78022020496a09878cf87704e47617731f551f201f9364c6cb4b904b48fd5e3ff3dd570121029fd3d2479a37f40d03975cb51ce0fa18cbb709cc46b47caeaa1722cfd3683583ffffffff0138840700000000001976a9148f4da084ec14ed710b96b6a086bbeb06d571faf988ac00000000 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
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 399
Merit: 22
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 20, 2024, 09:21:13 PM |
|
I will join and create my transaction with 6.6 BTC fees ![Cool](https://bitcointalk.org/Smileys/default/cool.gif) This is exactly what will happen. Someone will pay a fee of 5 BTC in order to earn 1.6 BTC. ![Grin](https://bitcointalk.org/Smileys/default/grin.gif)
|
|
|
|
albert0bsd
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 21, 2024, 12:12:33 AM Last edit: July 21, 2024, 12:28:14 AM by 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. ![](https://ip.bitcointalk.org/?u=https%3A%2F%2Fwww.talkimg.com%2Fimages%2F2024%2F07%2F21%2F4IGV1.th.png&t=665&c=6YJUSF5FpCtUJg) 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) ![](https://ip.bitcointalk.org/?u=https%3A%2F%2Fwww.talkimg.com%2Fimages%2F2024%2F07%2F21%2F4IMDm.th.png&t=665&c=7FvGGDa1lZyBhw) Another One 29 sat/vB ![](https://ip.bitcointalk.org/?u=https%3A%2F%2Fwww.talkimg.com%2Fimages%2F2024%2F07%2F21%2F4IRgC.th.png&t=665&c=g5fqHEeMxFffbQ) 44 sat/vB ![](https://ip.bitcointalk.org/?u=https%3A%2F%2Fwww.talkimg.com%2Fimages%2F2024%2F07%2F21%2F4Itdb.th.png&t=665&c=QTy3KrHoaQsxNA) 52 sat/vB ![](https://ip.bitcointalk.org/?u=https%3A%2F%2Fwww.talkimg.com%2Fimages%2F2024%2F07%2F21%2F4IzFv.th.png&t=665&c=awBW61jxtRe32w) 64 sat/vB ![](https://ip.bitcointalk.org/?u=https%3A%2F%2Fwww.talkimg.com%2Fimages%2F2024%2F07%2F21%2F4IFoH.th.png&t=665&c=9BFmeiCa9exBZA) 77 sat/vB ![](https://ip.bitcointalk.org/?u=https%3A%2F%2Fwww.talkimg.com%2Fimages%2F2024%2F07%2F21%2F4INlg.th.png&t=665&c=BOk3AoKGir51Hg) 93 sat/vB ![](https://ip.bitcointalk.org/?u=https%3A%2F%2Fwww.talkimg.com%2Fimages%2F2024%2F07%2F21%2F4II6I.th.png&t=665&c=OB3nNxBFFNT-NQ) 111 sat/vB ![](https://ip.bitcointalk.org/?u=https%3A%2F%2Fwww.talkimg.com%2Fimages%2F2024%2F07%2F21%2F4Isjd.th.png&t=665&c=UoaPOl-xUZjO9A) 135 sat/vB ![](https://ip.bitcointalk.org/?u=https%3A%2F%2Fwww.talkimg.com%2Fimages%2F2024%2F07%2F21%2F4I3D5.th.png&t=665&c=oCshx4Glg25kSQ) 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 ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) 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
Newbie
Offline
Activity: 20
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 21, 2024, 12:38:19 AM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 21, 2024, 03:26:43 AM |
|
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 #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
Newbie
Offline
Activity: 23
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 21, 2024, 03:33:42 AM |
|
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 #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
Newbie
Offline
Activity: 8
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 21, 2024, 04:46:44 AM |
|
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. ![Grin](https://bitcointalk.org/Smileys/default/grin.gif) 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 ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) 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
Jr. Member
Offline
Activity: 48
Merit: 1
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 21, 2024, 05:07:17 AM |
|
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
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 399
Merit: 22
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 21, 2024, 05:55:25 AM Last edit: July 21, 2024, 06:12:51 AM by 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
Newbie
Offline
Activity: 20
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 21, 2024, 06:42:49 AM |
|
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.gifThe 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
Jr. Member
Offline
Activity: 82
Merit: 8
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 21, 2024, 09:00:52 AM |
|
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/197kFKvMHoRJPXktc8xJwMjeTuE9xijBQAfter 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
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 116
Merit: 24
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 21, 2024, 09:26:31 AM |
|
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
Jr. Member
Offline
Activity: 48
Merit: 1
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 21, 2024, 11:31:42 AM |
|
So, bitcoin-devs can change RBF (BIP 125) rules that this scenario cannot happen? Do any of them even look at this topic here? ![Cry](https://bitcointalk.org/Smileys/default/cry.gif)
|
|
|
|
pbies
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 21, 2024, 11:38:47 AM |
|
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.
|
BTC: bc1qmrexlspd24kevspp42uvjg7sjwm8xcf9w86h5k
|
|
|
AlanJohnson
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 105
Merit: 11
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 21, 2024, 12:04:33 PM |
|
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
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 399
Merit: 22
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 21, 2024, 12:17:12 PM |
|
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/197kFKvMHoRJPXktc8xJwMjeTuE9xijBQAfter 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.gitcd 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
Newbie
Offline
Activity: 15
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 21, 2024, 12:31:29 PM |
|
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/197kFKvMHoRJPXktc8xJwMjeTuE9xijBQAfter 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.gitcd 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.
|
|
|
|
pbies
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 21, 2024, 12:33:47 PM |
|
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. Yes, it is possible. Just dividing pubkey by some values. Hitting the pvk is matter of even 2 seconds as other fella said here.
|
BTC: bc1qmrexlspd24kevspp42uvjg7sjwm8xcf9w86h5k
|
|
|
|