The difference comes from how that wordlist is used.

With BIP39, the wallet must know your wordlist in order to verify your checksum. If it does not know your wordlist, then it does not know what bits the words represent, so it cannot calculate the checksum, nor compare it to the bit string to see if it is correct.
With Electrum, the wallet does not need to know your wordlist at all. The versioning system is based on a hash of the words, not the original entropy that those words encode, so even without knowing the wordlist Electrum can hash your seed phrase, check the version number, and tell you if that seed phrase is valid (as well as whether it is a legacy or a segwit wallet).

It depends on your software. Electrum will import it just fine, but many wallets will only accept English words.

It's not. Electrum will quite happily restore a seed phrase generated using any wordlist, even one it does not know.

Here's a post I made several years ago, in which I share an Electrum seed phrase using a non-standard wordlist which I have long deleted, on a much older version of Electrum. You can still import that seed phrase without any issues in to your version of Electrum and arrive at the same address I did back then.

There are disadvantages to every method, and there is method in existence which can guarantee you will be 100% safe.

There are several disadvantages to any physical entropy generation. I think the biggest one is there being bias in your system which you are unaware of, cannot detect, or cannot correct. This is why I would recommend the coin flipping approach I explained above, which completely removes any bias. This kind of bias removal is incredibly complicated when it comes to rolling dice, and so I don't suggest it because no one would actually use it.

There is also the risk of your human brain taking over and messing up the process. For example, if you roll "4" five times in a row, there is a temptation to think "That's not very random, I'll just discard that and try again." Or if you roll five dice instead of just one, then there is the problem of choosing which order to read them in. A human brain might choose 4-2-3-1-4 instead of 1-2-3-4-4, because the former "looks" more random. You have to be strict and not interfere with the result in any way.

And there is the risk of how you complete the final steps of generating the checksum and encoding the whole string as a seed phrase. Using the method of simply picking a final word which fits is a poor one, because again it decreases your entropy. Instead, you need to generate the entropy of the final word and calculate the checksum. This requires a computer, which introduces a risk unless you are using a properly airgapped computer, ideally running a live OS.

If you take in to account what I've described above, then it is unlikely that someone would be able to recreate your process unless they are able to spy on you doing it in the first place (so remove any phones or other devices with a camera from the room while you are doing it, and make sure doors and curtains are closed), unless you are using biased dice which grossly reduce your entropy (although most people would never actually know because they would never test their dice in the first place).

Check out some decentralized exchanges: https://kycnot.me/. You might find some local activity.

Yup. Every centralized exchange is the same.

By all means, but these platforms have already collapsed and declared insolvency (exactly because they were doing what I highlighted above - gambling all their users' deposits in order to try to make themselves more profit).

It's impossible to read the terms for every single website or service that you use, but when it comes to something that you are going to be sending money to, then people should really take the time to figure out just what they are signing up for. In the case of centralized exchanges, it is usually a case of signing away all your coins, all your privacy, and all your rights.

Pretty much every centralized exchange has words to the same effect buried somewhere in their legal documents. The fact is that as soon as you deposit your coins to any centralized exchange, they do not belong to you and the exchange can do anything they like with them, including simply keeping them for themselves. It happens all the time, but everyone thinks "Well, it won't happen to me", right up until it does and they lose all their money.

The exact same thing happened with the likes of Celsius, Voyager, and BlockFi. Here's a post I made several years ago warning people about these platforms: https://bitcointalk.org/index.php?topic=5315224.msg56289293#msg56289293. In it, I point out that their terms quite clearly state that they will lend out, gamble and sell your coins, all while keeping zero collateral, and you have absolutely zero rights if it all goes to shit. Fast forward several years and these platforms collapse because of this exact reason, and all their users are shocked that they were engaging in the exact behavior they said they were engaging in, because none of the users had bothered to read the terms.

I've not used Bluewallet, but with Sparrow it is not necessary to back up the fingerprint. If you are entering a seed phrase for a cosigner then the master fingerprint can be derived, and if you are entering an xpub for a cosigner then you don't need to know the master fingerprint.

In terms of derivation path, Sparrow uses the following for it's multi-sig wallets which conform to both the BIP45 and BIP48 standards, so no need to back them up:

Legacy (P2SH) - m/45'
Nested Segwit (P2SH-P2WSH) - m/48'/0'/0'/1'
Native Segwit (P2WSH) - m/48'/0'/0'/2'

This is correct.

Although rolling a dice as explained in this thread is probably safe enough, without excluding bias you cannot be certain what your final entropy actually is. I'm not a fan of taking shortcuts or making assumptions like that when you are talking about generating a seed phrase to store large amounts of bitcoin.

My preferred method of physical entropy generation is to flip a coin using von Neumann's debiasing approach. With this method, you flip a coin twice. If the result is HH or TT, you discard it. If the result is HT you write down 1, and if it is TH you write down 0. This removes any and all bias from the coin, and gives you a perfect 50/50 chance of either a 0 or a 1. Repeat this process until you have 256 bits of entropy. Then either calculate out the checksum yourself using SHA256 and then manually encode everything in to words, or use an open source tool on an airgapped computer to do it for you, such as this one: https://bitcointalk.org/index.php?topic=5373505.0

I wouldn't call it an ego conflict, simply conflicting standards. It reminds me of this: https://xkcd.com/927/

I do agree things should be kept as simple as possible, but if someone is already in the situation in which they are trying to recover a non-standard or invalid BIP39 seed phrase using an unknown wordlist, then they have already failed at keeping things as simple as possible. As I mentioned above, this feature in Electrum is a recovery tool for people who have already over-complicated things with such non-standard seed phrases. If you keep things simple by installing Electrum and generating a new seed phrase for your wallet, then you will never interact with this feature at all.

I agree, but there are plenty of bad wallets out there which do all kinds of weird and non-standard things with seed phrases, derivation paths, and so on.

Of course a wordlist is a good thing. I've never said otherwise.

The difference is in how that wordlist is used. With BIP39, if you use a non-English wordlist, then most wallets have no idea if your seed phrase is valid or not, many will not yet you import it, and if they do import it will have no idea which script type or derivation path to use to generate a wallet. With Electrum, if you use an non-English wordlist, then Electrum will verify it just fine, import it just fine, and generate the exactly correct script type and derivation path without any further input from you. This is clearly a superior system.

Anyone who doesn't speak English can very easily import their own native language wordlist in to Electrum if they so choose and use it to generate a seed phrase. That seed phrase will be compatible with every copy of Electrum in the world, even if they lose their original wordlist.

I'm not certain what you are referring to by fingerprints. Bitcoin public keys generally don't use fingerprints like PGP keys do. Fingerprints are used in some descriptors, but that's not really relevant here when generating a multi-sig wallet using seed phrases.

In terms of the derivation path, the answer is maybe. Some people would say yes. I would say that as long as you are using a standard derivation path which will be easy to recover from, then probably not.

For example, I have a multi-sig wallet which was created using Electrum. The derivation paths Electrum uses for its multi-sig wallets are in the open source code and are widely known, so I didn't feel the need to back them up.

As hosseinimr93 says, you need the threshold number of seed phrases (so 2 in a 2-of-3 system, or 3 in a 3-of-5 system), and you also need the xpubs from the other cosigners.

There are two ways you can go about this. Some people simply back up all their xpubs together in addition to backing up their seed phrases separately. This isn't a great solution for me, because if someone discovers your xpub back up then they can generate your addresses and spy on your wallet. Although they won't be able to spend any coins, they can derive your addresses, see how many coins you have, watch your transactions, and so on.

The way I go about this is as follows. Alongside each seed phrase back up, I also back up a number of other xpubs, such that recovering the threshold number of back ups is enough to recover the entire wallet, but any one back up does not allow an attacker to spy on my wallet. So, for a 2-of-3 system, my back ups look like this:

Back up 1: Seed A, xpub B
Back up 2: Seed B, xpub C
Back up 3: Seed C, xpub A

As you can see, any two back ups will provide me with two seed phrases plus the third xpub, while any one back up does not allow an attacker to spy on my wallet.

For a 3-of-5 system, it would look like this:

Back up 1: Seed A, xpub B, xpub C
Back up 2: Seed B, xpub C, xpub D
Back up 3: Seed C, xpub D, xpub E
Back up 4: Seed D, xpub E, xpub A
Back up 5: Seed E, xpub A, xpub B

This has the same result, where any three back ups provide all the necessary information.

Obviously this can be a little complex to set up to ensure you are not mixing up your seed phrases and your xpubs, so if you plan to do this take your time, double check everything, and practice restoring your wallet from your back ups to ensure they are correct.

While everything you have said is true, Coinbase's policies are far more wide reaching than that. They essentially give Coinbase the ability to close your account and seize your coins for literally any reason at all, and there is nothing you can do about it. For example:


At any time, for any reason, and they won't even tell you why, let alone let you appeal against it.

And as we have seen from several recent court cases and bankruptcy proceedings, the instant coins are deposited to a centralized exchange, then legally speaking those coins belong to the exchange and you have absolutely no claim over them. There are thousands of such users who have had various centralized exchanges simply seize their coins with no explanation ever given.

A few points to consider.

In your current set up, you obviously have two back ups of each single sig wallet's seed phrase, because if you only had one back up and you lost it, then your wallet is unrecoverable. This is not the case with a multi-sig wallet. Even if you only had one back up of each seed phrase, then you can lose a single back up and still recover your wallet with the other two back ups. If you think your main weakness is one or more of your back ups being discovered, then you could reduce the number of back ups from six to three. You would have less redundancy, but you still would not have a single point of failure.

Alternatively, you could use a 3-of-5 system, again with a single back up of each seed phrase. This would require five back ups instead of six, but would require an attacker to access three of them instead of two of them in order to steal your coins. It would also allow you to lose up to two of your back ups and still recover your wallet.

It mostly depends on how secure your storage locations are against theft and against loss, and finding the balance between security against theft and redundancy against loss. Only you can answer that for your particular situation.

Technically kind of, but practically no.

They are not quite the same thing. The root key is derived from your seed phrase, and is the first step in deriving the rest of your wallet.

It is correct to say that you could use either of them to derive all the private keys and addresses from any derivation path, however, the vast majority of wallets will only allow to import a seed phrase and will not allow you import master private keys. Additionally, it is significantly easier to write down and import a seed phrase without making any mistakes than it is to do the same with a master private key.

In short, back up your seed phrase and ignore your master private keys. The vast majority of users do not need to handle raw private keys, and if you don't know what you are doing then doing so is a security risk.

If you are using mempool.space, you can tell that they are not actually purging transactions from their mempool by the graph underneath the "Memory usage" bar which you posted. At the moment it states it is purging anything below ~2 sats/vbyte, and yet the graph still shows almost 40 MvB of transactions paying between 1 and 2 sats/vbyte.

Compare this to Johoe's mempool here: https://jochen-hoenicke.de/queue/#BTC%20(default%20mempool),8h,weight.
He is showing only around 3 MvB of transactions paying between 1 and 2 sats/vbyte. It seems he is indeed purging at around 300 MB of memory use.

My biggest issue with using a die or dice to calculate your seed phrase is that most dice have some inherent bias, unless you are buying casino grade dice which almost nobody will actually do. Further, testing for this bias is a long and complex process, as is any method used to eliminate said bias, which again, almost nobody will actually do. This means you are generating a seed phrase with a lower amount of entropy than you think.

Also, the final word in any BIP39 seed phrase is not purely checksum, and contains some entropy as well. If you are arbitrarily picking that word, instead of generating the necessary amount of entropy first and then using SHA256 to calculate the checksum as you should be doing, then again you are decreasing your final entropy.

Don't forget that there is a constant stream of new users in to this space who are unaware of just how risky centralized exchanges are and just how many of them collapse. There are undoubtedly more people moving their money off of centralized exchanges permanently, but there are also plenty of brand new users who have not yet been stung by the collapse of an exchange to replace them.

We would never know. Binance have spent a lot of effort on keeping their actual operations as obfuscated as possible. Difficult to know even where their offices are or which country they are registered in half the time, they move around so much. Every platform which has collapsed recently - FTX, Voyager, Celsius, BlockFi, etc. - were all loudly tweeting and blogging about how great they were doing and how fUnDs ArE sAfU right up to the day or two before they collapsed.

Tether hasn't been backed by real dollars in years (if ever). This has been proven in court on multiple occasions. It is a fractional reserve, with more being printed out of thin air at will, and yet for some reason people still use it.

It doesn't matter how much computational power you have if I refuse to run your code. You can hack the whole of GitHub and upload malicious software in to every repository in existence, not just Bitcoin Core. None of that achieves anything unless people actually download and run your malicious software.

And of course as the computational power of a malicious attacker increases, then the computational power of honest users, honest nodes, security software, etc., also increases at the same rate.

Ahh, right. You are talking about PSBTs, which are in Base64, rather than a raw transaction in hex. I don't think Electrum lets you export unsigned transactions in hex anymore. So yeah, if you want to use hex encoding rather than Base64, you'll need to use different software.

You'll also save yourself a lot of time. Your PSBT has 1,308 characters. A similar one-input one-output legacy-to-legacy transaction in raw hex has "only" 382 characters.

It is trivial for a criminal to buy your leaked KYC data on the dark web for a couple of bucks and sign up to any centralized exchange using your details. KYC does not help an exchange to "weed out" criminals.

If I keep my coins in my own wallet, then I can take security precautions against them being hacked. If I hand over my KYC details (or my coins) to a centralized exchange, then there is absolutely nothing I can do to protect them and history has shown us time after time after time that centralized exchanges have awful security and are being hacked constantly.

So you want the government to step in and have complete control over bitcoin just as they do with fiat? Um.... no?

It's certainly doable, just not very convenient. Fine if your wallet really is long term cold storage though with very few (if any) outgoing transactions.

What format are you using? Raw transactions should be in hex, so 0-9 and A-F. There are no easily confused characters there.

For my long term cold storage, I probably don't want many new features such as Taproot and Lightning. Keep everything as simple as possible to reduce any attack surface to an absolute minimum.