You are confused about how signatures work.

The .asc file you verify contains a signature from a developer pointing to a specific file. The signature is generated using both the file in question and the developer's private key. If even a single byte in the file is changed, then the signature is no longer valid.

You can test this yourself by downloading the signatures for an older version of Electrum (such as 4.4.5) and trying to use those signatures to verify the latest version (4.4.6). Although the signatures are valid signatures from the devs, they will fail to verify because you are using them to verify a different file.

If an attacker uploads a malicious version of Electrum, then the signatures from the devs will not verify. If they replace the signatures with their own, then it will be obvious that it was not signed by the devs but by someone else.

RBF is not consensus - it's policy.

There has been nothing stopping nodes from accepting full RBF transactions, or from miners mining full RBF transactions, since day one of bitcoin. It is a local policy in Bitcoin Core to enforce opt-in RBF, but any node could have opted out of that and accepted full RBF transactions at any time, which is why zero confirmation transactions were never safe. The recent change to implement the full RBF setting simply makes it easier for nodes to do that, and will eventually move towards that being the default setting. But again, that will be policy, not consensus. Any node will still be free to reject full RBF transactions if they wish.

Change this BTC.txt file to something along the lines of this:


Keep going with as many additional account numbers as you want, checking the receiving and change paths for each one. Each additional path you add will prolong your search time, however. Then run the same command again, but leave out the --bip32-path argument. Since you are specifiying --wallet-type BIP39, btcrecover will check all the paths you specify in the BTC.txt file. You might also want to drop the --addr-limit to a smaller number to speed things up a bit.

I agree with Loyce though, this sounds like nonsense.

Lower nSequence values imply a relative timelock, as specified by BIP68.

In terms of RBF, no. The nSequence number signals replaceability, but higher nSequence numbers are not prioritized over lower ones. It is based on fee alone.

Strictly in terms of the RBF, it makes no difference. But it could make a difference if your replacement transaction includes a timelock which means it can not yet be mined.

Yes. The nSequence is irrelevant when it comes to full RBF. Full RBF means any transaction can be replaced, provided the replacement transaction meets the other requirements as stipulated in BIP125 regarding unconfirmed inputs, fees, and evictions.

In the case of the puzzle hunters that you have brought up, the only safe way for the puzzle hunter to get their transaction mined will be to mine it themselves, in secret. As soon as they broadcast the transaction using any method (even their own full-RBF-disabled node), then it is at risk of being replaced. If they share it privately with a third party miner, then that miner could replace it as well.

Yes. The NSA have admitted they can easily track phones, even with all connectivity disabled and airplane mode turned on:


Most phones these days are quite happy to allow WiFi and Bluetooth to be activated even when airplane mode is turned on, since you are now allowed to use these things in most aircraft. Further, it is almost impossible for the average person to actually verify that their phone is not transmitting information via some method. The only way to be certain that your airgap is effective is to use a device which does not have the capabilities to transmit data in the first place. This almost always means an old computer or a SBC without a WiFi card, Bluetooth module, etc.

They are anti-privacy and actively support blockchain analysis via their partnership with Wasabi.

I'm probably never going to store that much money in a hardware wallet (or indeed, in a single wallet at all). Multiple separate cold storage wallets is the way to go.

Although I would also be using a separately generate and secure passphrase, so even if my seed phrase was compromised my funds would still be protected.

For an open source and airgapped hardware wallet, yes. For a Ledger device, no.

Perhaps a more fair comparison would be against bitnodes' Global Node list.

I wouldn't say altcoins are like a VPN at all. Many have even worse privacy than bitcoin does. Just take the biggest altcoin Ethereum as an example - they use an account based model rather than an UTXO based model, meaning all your ETH transactions (and all your stupid token transactions too) are all intrinsically linked together.

I don't know why people continue to ask these AI models anything technical, especially when it comes to bitcoin. They are consistently wrong and can easily be prompted in to providing any answer.

It can't be infinite since there are a maximum possible number of bitcoin addresses.

If we are considering only one type of bitcoin address (such as P2WPKH addresses), then there are "only" 2¹⁶⁰ possible addresses, since each address encodes the output of a RIPEMD-160 hash. But it is correct to say that every possible P2WPKH address could be generated from a single seed phrase, if you scanned enough derivation paths. My answer that Zaguru12 has quoted above explains why. Doing this is obviously impossible, though, and is akin to simply brute forcing all possible private keys.

Does it run if you leave out the --enable-opencl argument? If it does, then it probably means you haven't installed the correct drivers or libraries for your GPU.

This is trivial to do using btcrecover.

First of all create a new text file with one word of the seed phrase per line. Something along the lines of this:


Then run the following command using btcrecover:


This will check every address between m/84/0'/0'/0/0 and m/84'/0'/0'/0/999 for every valid combination of your 12 words. If this is very slow on your hardware, you can experiment using GPU acceleration by following the instructions here and adding the relevant arguments to your command: https://btcrecover.readthedocs.io/en/latest/GPU_Acceleration/

Software level airgap - you have turned off your WiFi in your OS.

Hardware level airgap - you have physically removed your WiFi card (or never had one to begin with).

No, he is right. You can indeed use the word "hello" as an entire seed phrase if you want. Obviously it doesn't follow the BIP39 protocol in terms of length, entropy, checksum, etc., but you can indeed ignore all that, feed "hello" in to the PBKDF2 algorithm, and generate a wallet. In fact, someone has done that already. Using the string "hello" as a BIP39 seed phrase, you can generate the following address at m/44'/0'/0'/0/1:

19ag68hqdbjwC2cLDZs5HRrxRCm4ETr2Wb

This address was used back in 2017.

Ledger no, because it is closed source and actively malicious. Trezor maybe since it is open source, but there are a variety of reasons I don't trust Trezor as a company so I'm never going to buy one of their products. I would use an entirely open source hardware wallet like Passport, though, where I can see exactly how it is generating its random numbers.

Be aware that there are attacks which can utilize your WiFi without you being connected to a network. Yes, these are far more complex and technical and require an attacker to be in your local vicinity, but they are still possible.

I wouldn't call it dangerous, per se, but just less secure than a hardware airgap. As I've said above, a software airgap is still much more preferable to a standard hot wallet.

I thought we were an autonomous collective.

JavaScript key generators are not secure, and there have been a number of vulnerabilities and poor implementations which have resulted in wide spread losses. You should substitute using a JavaScript based website for a piece of good open source wallet software which uses properly secured random number generation, such as Bitcoin Core, Electrum, or Sparrow.

Use Linux instead.

Once you've downloaded the wallet software you are going to use, you need to verify it against the developer's signatures before transferring it to your airgappd computer.

You mean disabling WiFi or other connectivity hardware in the BIOS settings? That is still a software level airgap. It's better than just turning them off in your OS since you can't accidentally turn them back up with a single misclick and need to go back in to your BIOS settings in order to re-enable them, but it is still a software airgap since the hardware is still there, is still functional, and is still connected up. This will never be as secure as a hardware airgap where the necessary hardware doesn't even exist in the device.

My concerns with a software level airgap are not that someone is going to be able to extract data via monitoring my fan speed or electricity usage or one of the other novel techniques which has been described, but rather that a software level airgap is only ever one misclick, one settings change (accidental or malicious), one tiny adjustment, etc., aware from becoming a hot wallet. Additionally, a software level airgap is almost impossible for the user to verify themselves. If you turn on airplane mode on your phone, how can you confirm and verify for yourself that your phone is not transmitting any data at all via cellular, WiFi, Bluetooth, NFC, RFID, and so on?

A hardware level airgap is simply much safer.

Know the derivation path. If you don't know it, you have to brute force it. Provided you've followed one of the various BIP protocols this will be easy enough to do. If you have used something non-standard, this might be easy or impossible.

For example, let's say I generated an address at something like this, and did not back up this path:


This is exponentially more difficult to brute force than a seed phrase itself, and so my coins on that path would be unrecoverable.