does anyone use blockchain.com, or knows if their account can import privatekeys there,
the coins inside are instantly visible right? then wait, why not instantly sell the coins to usdt?
this seemed the option for me i guess, without caring for forks, greets dex, will it works?
Topic: Bitcoin puzzle transaction ~32 BTC prize to who solves it - page 84. (Read 244737 times)
So friend, the entire test was done with an old version of electrum, where it was possible to deactivate the RBF option, as you can confirm in the transaction itself that it was deactivated, perhaps electrum removed this option from the wallet in the most recent updates because miners did not they were respecting it, in other words, it doesn't make sense to have the tool and it not work as it should.
I usually only use terminal commands to send and receive crypto. I used it for the bot, and even there it is not used through the GUI, only as an Electrum daemon.
Which tool can bypass RBF, if any?
13zb1hQbWV 50 pieces.
13zb1hQbWVs 2 pieces.
13zb1hQbWVs 2 pieces.
13zb1hQbWV 10 char match in ripemd160 hash will be little reference significance
#0x20000000000000000 ~ 0x40000000000000000 have 10000+ private key has 10 char match compressed address
13zb1hQbWVs 11 char match
#0x20000000000000000 ~ 0x40000000000000000 have 200~250 private key has 11 char match compressed address
13zb1hQbWVsc 12 char match
#0x20000000000000000 ~ 0x40000000000000000 have 3~4 private key has 12 char match compressed address
I found 13zb1hQbWVsSAaNvpKfmc43NsuAj33LyRM in range 0x20000000000000000 ~ 0x40000000000000000 last month
But I still don't know which range I should jump and keep search
Hi all. In principle, I didn’t plan to write here, I’ll just write as a participant.
You are welcome bro 
13zb1hQbWV 11 char practice 2*66-2.67/58
13zb1hQbWVs 12 char practice V*58=1 Vs
What do you have in mind? i have 13zb1hQbW 3000pcs, 65 WV pcs, 3 WVs pcs. This is all very pointless, I repeat, I collected this as a log of passed ranges. I disabled some of my GPUs today and was disappointed with some of the forum posts. Most likely tomorrow I will turn off the GPUs that are still in use,maybe. I also took part in a bot battle on stream with a Portuguese guy. Sry i use transalter.
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..
So friend, the entire test was done with an old version of electrum, where it was possible to deactivate the RBF option, as you can confirm in the transaction itself that it was deactivated, perhaps electrum removed this option from the wallet in the most recent updates because miners did not they were respecting it, in other words, it doesn't make sense to have the tool and it not work as it should.
13zb1hQbWV 50 pieces.
13zb1hQbWVs 2 pieces.
13zb1hQbWVs 2 pieces.
13zb1hQbWV 10 char match in ripemd160 hash will be little reference significance
#0x20000000000000000 ~ 0x40000000000000000 have 10000+ private key has 10 char match compressed address
13zb1hQbWVs 11 char match
#0x20000000000000000 ~ 0x40000000000000000 have 200~250 private key has 11 char match compressed address
13zb1hQbWVsc 12 char match
#0x20000000000000000 ~ 0x40000000000000000 have 3~4 private key has 12 char match compressed address
I found 13zb1hQbWVsSAaNvpKfmc43NsuAj33LyRM in range 0x20000000000000000 ~ 0x40000000000000000 last month
But I still don't know which range I should jump and keep search
Hi all. In principle, I didn’t plan to write here, I’ll just write as a participant.
You are welcome bro 13zb1hQbWV 11 char practice 2*66-2.67/58
13zb1hQbWVs 12 char practice V*58=1 Vs
Several people asked me via private message to send them the script I used.
Here is the script.
I don't have an automatic fee increase like Alberto does. My fee was static at about $12 (0.00018 BTC), while Alberto raised his to $17 and won. In addition to Electrum, these other codes can also be used as a backup.
You need to install the BSGS server to work with this one.
p.s.
You can edit def bump_fee_and_redirect to have an automatic fee increase:
Here is the script.
Code:
import requests
import time
import subprocess
import os
import re
from datetime import datetime
import secp256k1 as ice
import json
import logging
# Setup logging
logging.basicConfig(level=logging.INFO)
def get_exact_public_key(address):
url = f'https://mempool.space/api/address/{address}/txs/chain'
response = requests.get(url)
if response.status_code != 200:
raise Exception(f"Error fetching transactions: {response.status_code}")
transactions = response.json()
for tx in transactions:
for vin in tx['vin']:
if 'scriptsig' in vin:
scriptsig = vin['scriptsig']
# Extract the public key from the scriptSig
# This assumes a standard P2PKH transaction where the scriptSig is in the format:
#
pubkey = scriptsig[-66:] # The public key is typically 66 characters long in hex
return pubkey
return None
def save_public_key(pubkey):
with open("66.txt", "w") as f:
f.write(pubkey)
def run_keyhunt(pubkey):
command = f"echo '{pubkey} 20000000000000000:3ffffffffffffffff' | nc -v localhost 8080"
logging.info(f"Running command: {command}")
result = subprocess.run(command, shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True)
logging.info(f"Keyhunt stdout: {result.stdout}")
logging.error(f"Keyhunt stderr: {result.stderr}")
return result.stdout
def extract_private_key():
try:
with open("KEYFOUNDKEYFOUND.txt", "r") as f:
for line in f:
if "Key found privkey" in line:
privkey = line.split("Key found privkey")[1].strip()
return privkey
except FileNotFoundError:
logging.error("KEYFOUNDKEYFOUND.txt not found")
return None
def convert_to_wif(privkey):
return ice.btc_pvk_to_wif(privkey)
def start_electrum_daemon():
command = "electrum daemon -d"
subprocess.run(command, shell=True)
time.sleep(1)
def stop_electrum_daemon():
command = "electrum stop"
subprocess.run(command, shell=True)
time.sleep(1)
def restore_wallet(wif_key, password):
command = f"electrum -w /root/.electrum/wallets/66 restore {wif_key} --password {password}"
result = subprocess.run(command, shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True)
logging.info(f"restore_wallet output: {result.stdout} {result.stderr}")
def load_wallet(password):
command = f"electrum load_wallet -w /root/.electrum/wallets/66 --password {password}"
result = subprocess.run(command, shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True)
logging.info(f"load_wallet output: {result.stdout} {result.stderr}")
def list_transactions():
command = "electrum onchain_history -w /root/.electrum/wallets/66"
result = subprocess.run(command, shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True)
logging.info(f"history output: {result.stdout} {result.stderr}")
try:
transactions = json.loads(result.stdout)
return transactions
except json.JSONDecodeError:
logging.error("Failed to decode JSON from electrum history output")
return []
def bump_fee_and_redirect(txid, new_address, new_fee_rate, max_attempts, bump_interval):
attempts = 0
while attempts < max_attempts:
attempts += 1
command = f"electrum bumpfee {txid} {new_fee_rate} --destination {new_address}"
logging.info(f"Running bumpfee command: {command}")
result = subprocess.run(command, shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True)
logging.info(f"bumpfee stdout: {result.stdout}")
logging.error(f"bumpfee stderr: {result.stderr}")
logging.info(f"Waiting for {bump_interval} seconds before next bump...")
time.sleep(bump_interval)
if attempts == max_attempts:
logging.error(f"Max fee bump attempts reached for transaction {txid}.")
def main():
wallet_path = "/root/.electrum/wallets/66"
password = "Satoshi"
new_address = "new_address_here"
initial_fee_rate = 0.00018
max_attempts = 20 # Maximum number of fee bumps
bump_interval = 2 # Time to wait between bumps in seconds
address = "197kFKvMHoRJPXktc8xJwMjeTuE9xijBQ"
while True:
logging.info("Running scan...")
pubkey = get_exact_public_key(address)
if pubkey:
logging.info(f"Extracted Public Key: {pubkey}")
save_public_key(pubkey)
# Uncomment to run Keyhunt (ensure you have the keyhunt tool and the correct parameters)
run_keyhunt(pubkey)
if os.path.exists("KEYFOUNDKEYFOUND.txt"):
privkey = extract_private_key()
if privkey:
logging.info(f"Private Key: {privkey}")
wif_key = convert_to_wif(privkey)
logging.info(f"WIF Key: {wif_key}")
stop_electrum_daemon()
start_electrum_daemon()
restore_wallet(wif_key, password)
load_wallet(password)
transactions_data = list_transactions()
transactions = transactions_data.get('transactions', [])
# Check if there are unconfirmed transactions
unconfirmed_transactions = [tx for tx in transactions if tx.get('confirmations') == 0]
if unconfirmed_transactions:
for tx in unconfirmed_transactions:
bump_fee_and_redirect(tx['txid'], new_address, initial_fee_rate, max_attempts, bump_interval)
else:
logging.info("No unconfirmed transactions to bump fee.")
stop_electrum_daemon()
break
time.sleep(1)
if __name__ == "__main__":
main()
import time
import subprocess
import os
import re
from datetime import datetime
import secp256k1 as ice
import json
import logging
# Setup logging
logging.basicConfig(level=logging.INFO)
def get_exact_public_key(address):
url = f'https://mempool.space/api/address/{address}/txs/chain'
response = requests.get(url)
if response.status_code != 200:
raise Exception(f"Error fetching transactions: {response.status_code}")
transactions = response.json()
for tx in transactions:
for vin in tx['vin']:
if 'scriptsig' in vin:
scriptsig = vin['scriptsig']
# Extract the public key from the scriptSig
# This assumes a standard P2PKH transaction where the scriptSig is in the format:
#
pubkey = scriptsig[-66:] # The public key is typically 66 characters long in hex
return pubkey
return None
def save_public_key(pubkey):
with open("66.txt", "w") as f:
f.write(pubkey)
def run_keyhunt(pubkey):
command = f"echo '{pubkey} 20000000000000000:3ffffffffffffffff' | nc -v localhost 8080"
logging.info(f"Running command: {command}")
result = subprocess.run(command, shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True)
logging.info(f"Keyhunt stdout: {result.stdout}")
logging.error(f"Keyhunt stderr: {result.stderr}")
return result.stdout
def extract_private_key():
try:
with open("KEYFOUNDKEYFOUND.txt", "r") as f:
for line in f:
if "Key found privkey" in line:
privkey = line.split("Key found privkey")[1].strip()
return privkey
except FileNotFoundError:
logging.error("KEYFOUNDKEYFOUND.txt not found")
return None
def convert_to_wif(privkey):
return ice.btc_pvk_to_wif(privkey)
def start_electrum_daemon():
command = "electrum daemon -d"
subprocess.run(command, shell=True)
time.sleep(1)
def stop_electrum_daemon():
command = "electrum stop"
subprocess.run(command, shell=True)
time.sleep(1)
def restore_wallet(wif_key, password):
command = f"electrum -w /root/.electrum/wallets/66 restore {wif_key} --password {password}"
result = subprocess.run(command, shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True)
logging.info(f"restore_wallet output: {result.stdout} {result.stderr}")
def load_wallet(password):
command = f"electrum load_wallet -w /root/.electrum/wallets/66 --password {password}"
result = subprocess.run(command, shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True)
logging.info(f"load_wallet output: {result.stdout} {result.stderr}")
def list_transactions():
command = "electrum onchain_history -w /root/.electrum/wallets/66"
result = subprocess.run(command, shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True)
logging.info(f"history output: {result.stdout} {result.stderr}")
try:
transactions = json.loads(result.stdout)
return transactions
except json.JSONDecodeError:
logging.error("Failed to decode JSON from electrum history output")
return []
def bump_fee_and_redirect(txid, new_address, new_fee_rate, max_attempts, bump_interval):
attempts = 0
while attempts < max_attempts:
attempts += 1
command = f"electrum bumpfee {txid} {new_fee_rate} --destination {new_address}"
logging.info(f"Running bumpfee command: {command}")
result = subprocess.run(command, shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True)
logging.info(f"bumpfee stdout: {result.stdout}")
logging.error(f"bumpfee stderr: {result.stderr}")
logging.info(f"Waiting for {bump_interval} seconds before next bump...")
time.sleep(bump_interval)
if attempts == max_attempts:
logging.error(f"Max fee bump attempts reached for transaction {txid}.")
def main():
wallet_path = "/root/.electrum/wallets/66"
password = "Satoshi"
new_address = "new_address_here"
initial_fee_rate = 0.00018
max_attempts = 20 # Maximum number of fee bumps
bump_interval = 2 # Time to wait between bumps in seconds
address = "197kFKvMHoRJPXktc8xJwMjeTuE9xijBQ"
while True:
logging.info("Running scan...")
pubkey = get_exact_public_key(address)
if pubkey:
logging.info(f"Extracted Public Key: {pubkey}")
save_public_key(pubkey)
# Uncomment to run Keyhunt (ensure you have the keyhunt tool and the correct parameters)
run_keyhunt(pubkey)
if os.path.exists("KEYFOUNDKEYFOUND.txt"):
privkey = extract_private_key()
if privkey:
logging.info(f"Private Key: {privkey}")
wif_key = convert_to_wif(privkey)
logging.info(f"WIF Key: {wif_key}")
stop_electrum_daemon()
start_electrum_daemon()
restore_wallet(wif_key, password)
load_wallet(password)
transactions_data = list_transactions()
transactions = transactions_data.get('transactions', [])
# Check if there are unconfirmed transactions
unconfirmed_transactions = [tx for tx in transactions if tx.get('confirmations') == 0]
if unconfirmed_transactions:
for tx in unconfirmed_transactions:
bump_fee_and_redirect(tx['txid'], new_address, initial_fee_rate, max_attempts, bump_interval)
else:
logging.info("No unconfirmed transactions to bump fee.")
stop_electrum_daemon()
break
time.sleep(1)
if __name__ == "__main__":
main()
I don't have an automatic fee increase like Alberto does. My fee was static at about $12 (0.00018 BTC), while Alberto raised his to $17 and won. In addition to Electrum, these other codes can also be used as a backup.
You need to install the BSGS server to work with this one.
p.s.
You can edit def bump_fee_and_redirect to have an automatic fee increase:
Code:
def bump_fee_and_redirect(txid, new_address, new_fee_rate, max_attempts, bump_interval):
attempts = 0
while attempts < max_attempts:
attempts += 1
command = f"electrum bumpfee {txid} {new_fee_rate} --destination {new_address}"
logging.info(f"Running bumpfee command: {command}")
result = subprocess.run(command, shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True)
logging.info(f"bumpfee stdout: {result.stdout}")
logging.error(f"bumpfee stderr: {result.stderr}")
if "Transaction successfully rebroadcast" in result.stdout:
logging.info(f"Fee bump attempt {attempts} successful.")
break
else:
logging.warning(f"Fee bump attempt {attempts} failed. Trying again...")
new_fee_rate *= 1.5 # Increase fee rate for next attempt
if attempts == max_attempts:
logging.error(f"Max fee bump attempts reached for transaction {txid}.")
attempts = 0
while attempts < max_attempts:
attempts += 1
command = f"electrum bumpfee {txid} {new_fee_rate} --destination {new_address}"
logging.info(f"Running bumpfee command: {command}")
result = subprocess.run(command, shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True)
logging.info(f"bumpfee stdout: {result.stdout}")
logging.error(f"bumpfee stderr: {result.stderr}")
if "Transaction successfully rebroadcast" in result.stdout:
logging.info(f"Fee bump attempt {attempts} successful.")
break
else:
logging.warning(f"Fee bump attempt {attempts} failed. Trying again...")
new_fee_rate *= 1.5 # Increase fee rate for next attempt
if attempts == max_attempts:
logging.error(f"Max fee bump attempts reached for transaction {txid}.")
Ok ... So why all the puzzles with lower ranges are still sitting there ? Why nobody can crack puzzle 130 ? If that would be possilble all the puzzles would be empty now and every day we would be hearing about stolen bitcoins after making transactions (and releasing public key).
Beacuase we don't know the public key of those, the public key is only know if the address made a outgoing transaction. Until that those address are “safe”
I know that ! But i was refering to a guy that suggest that ALL bitcoin transactions are unsafe and can be cracked which is untrue in my opinion (and that's why i said about all the puzzles like 130 that wasn't cracked to this time even when their public keys are known).
Once again: You can't crack a proper 256bit private key even when i tell you the public key to it. I guess at some point it will be possible but not with currently available hardware.
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?
It is NOT safe, most of those services only works with Transactions already stuck on mempool.
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
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
Thank you for sharing your research, I think that once the TX Is mined then that page move it from mempool to main, most pages discard all other TX once that the block is mined and those transactions are market as invalid or with conflicts ( because the utxo is already mined )
I already share how to I do it. I don't do anything special or different.
use API broadcasts to blockchain
response = requests.post(
'https://blockchain.info/pushtx',
data={'tx': raw_tx}
)
print(response.text)
response = requests.post(
'https://blockchain.info/pushtx',
data={'tx': raw_tx}
)
print(response.text)
thank you i didn't know this API i will add to my script as backup method
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
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
I don't do anything special.
- spam the mempool with multiple TX with different output addresses and fees
each time that the transaction fail I increment the fee by 10% and resend it until it was accepted by the mempool API, then my bot sleep for 30 seconds just to recheck if my previous TX is still the higher transaction fee if no, then it repeat the process again
Ok ... So why all the puzzles with lower ranges are still sitting there ? Why nobody can crack puzzle 130 ? If that would be possilble all the puzzles would be empty now and every day we would be hearing about stolen bitcoins after making transactions (and releasing public key).
Beacuase we don't know the public key of those, the public key is only know if the address made a outgoing transaction. Until that those address are “safe”
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.
Ok ... So why all the puzzles with lower ranges are still sitting there ? Why nobody can crack puzzle 130 ? If that would be possilble all the puzzles would be empty now and every day we would be hearing about stolen bitcoins after making transactions (and releasing public key).
Yes, we can divide any public key by any number, but we will never know in what range to look for it.
We can't even divide by 2 with 100 confidence that the division was done correctly, since the parity of the public key is unknown.
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.
Ok ... So why all the puzzles with lower ranges are still sitting there ? Why nobody can crack puzzle 130 ? If that would be possilble all the puzzles would be empty now and every day we would be hearing about stolen bitcoins after making transactions (and releasing public key).
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.
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
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.
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
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..
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.
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.
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.
Quote
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?
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.
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.
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
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)
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://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
Quote
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
Jump to: