Which is clearly a weakness. If I import a BIP39 seed phrase generated with an incorrect wordlist, a foreign language wordlist, an edited wordlist, etc., then my wallet software cannot tell me whether or not it is accurate. The dependence on a known wordlist is a weakness, because now I don't know whether my seed phrase is correct or not, and I have to go searching for some software which will allow me to attempt to import it.

Not at all. I don't speak Portuguese, but if I had a Portuguese seed phrase with one or two character errors in it, then it is trivial for me to start looking up words in a Portuguese dictionary to see which one might be spelt incorrectly. I can't do that with raw hex.

Because without knowing the wordlist, they have no way of knowing if a random string with any random characters is an incorrectly generated BIP39 seed phrase. They only ever call a phrase BIP39 after the user has checked the box indicating that they are entering a BIP39 phrase.

If I say "Here is a BIP39 seed phrase" and then enter some random string, Electrum (or any other software) has absolutely no way of saying "This is not a BIP39 seed phrase". All it can do is take me at my word, and tell me that it doesn't know the specifics of my BIP39 seed phrase, since I could be using any wordlist or any non-standard implementation. Plenty of other software already generates what they call BIP39 seed phrases which do not follow the standard. Iancoleman, for example, lets users generate seed phrases with only 3 words.

There is also the cost basis involved. It costs a lot of money to set up a high tech security system and pay armed security guards to protect your mansion 24/7. It costs nothing to download and use Tails with your internet connection disabled (although obviously better on a permanently airgapped device).

I have pretty much this exact set up for interacting with some of my cold wallets. One thing to remember though - unless you want to transcribe your transactions from the raw hex by hand, you need some way to transfer them electronically. So either leave the camera in but cover it with tape when not in use, or remember not to glue a SD card slot or USB port.

An uncompressed public key takes the form of a 0x04 byte, followed by the 32 byte x coordinate and the 32 byte y coordinate, for 65 bytes in total.

Each x coordinate on the secp256k1 curve has exactly two possible y coordinates, one of which is even, and one of which is odd. So knowing which y coordinate your public key has, you can compress your public key to either an 0x02 byte if the y coordinate is even, or an 0x03 byte if the y coordinate is odd, followed only by the 32 byte x coordinate, for 33 bytes in total. The y coordinated can be derived from knowledge of the x coordinate and whether the y coordinate is positive or negative.

There are the same number of compressed and uncompressed public keys. There is a 1-to-1 correlation. Each uncompressed public key has exactly one compressed public key which is derived from the same private key. If you change the 0x02/0x03 byte on a compressed public key, then that corresponds to a different uncompressed public key (which happens to be derived from the original private key negated mod n).

The public key must be in the exact uncompressed or compressed format as I have described above. As part of the unlocking script, you must provide a valid signature for that public key. If your public key is misformed, then your signature will fail.

None. Every valid public key is of the format I described above.

You do not need to have access to the original wordlist in order to recover an Electrum seed phrase. You can take the bunch of bananas (pun intended ) nc50lc has posted above and use them to recover the original wallet in your Electrum client, without ever knowing the original wordlist he used. The same is true for alphanumeric gibberish or any other wordlist. If an attacker attempts to import it in to any recent version of Electrum, it will work just fine.

His numbers are actually a little off.

For 33.55% of the hashrate, the probability an attacker is successful after 1 confirmation is 70.12%, after 3 confirmations is 43.54%, and after 6 confirmations is 23.09%.

On closer examination of the code here, it seems the error is that his calculation is not taking in to account fractions of a percent. You can test this yourself by putting in the hashrate box, for example, 30 and 30.999, and seeing they produce the same result.

Great job ignoring all the other points, as well as providing a single example of a coinjoin while also ignoring the links I provided which show address reuse and toxic change.

Wasabi are pro-censorship and anti-fungibility, and therefore are anti-bitcoin. It is a mistake for BTCPay to implement this. Even if someone manages to get enough volume on a coordinator which doesn't spy on users and directly fund blockchain analysis, then they are still risking address reuse and therefore complete failure of what they are trying to achieve by coinjoining in the first place.

In an ideal world, yes, but only if addresses are never reused, which we know is not the case. And actually, if you were to never reuse an address, then it does not really matter from a security nor a privacy point of view (when it comes to someone stealing your private key or linking your transactions) if you were to use an account model or an output model. The difference is that an account model actively encourages address reuse, which is obviously bad for privacy but also for fungibility, as I mentioned above, and there are network level security implications, such as replaying previous transactions.

So we can rid the space of the largest, most toxic, most centralized player, which attacks bitcoin itself while actively lying and scamming its users, and harvests data and funds blockchain analysis, while at the same time having a flash sale where I can buy bitcoin at a discount? Sign me up!

No such thing exists. Every big centralized exchange has too much money and power to be anything other than corrupt. The whole point is that trust should not be needed.

It depends on the specifics of the platform you are using. All will have protocols in place for this kind of thing, which usually involves releasing the bitcoin to the buyer along with a penalty taken from the seller, unless the two individuals come to some other agreement (i.e. the seller refunds the buyer). For Bisq, you can see the examples here: https://bisq.wiki/Table_of_penalties.

So for the seller not releasing the BTC within the trade window, then the arbitrator would give the buyer the full amount of bitcoin they were owed from the escrow, along with 15% of the seller's security deposit as punishment.

For Bisq, that's where the arbitrator comes in.

It's not always as simple as that, though, and installing a custom ROM can open you up to a variety of other risks instead: https://www.privacyguides.org/en/os/android-overview/

A fer better option is simply not to use a phone for any serious amounts of money at all. It is very easy to download and flash Tails to a USB drive and use a live OS with your internet disconnected, which will be exponentially more secure than any hot wallet on any phone, stock or custom ROM.

You should obviously keep your OS up to date, but if you are generating keys on an online computer then you should consider those keys as having as low a security as any hot wallet, regardless of your OS. I wouldn't use an old OS since there have been plenty of examples of ones with bugs or vulnerabilities in their random number generators. Better to use Tails (or some other reputable Linux distro) as above.

Essentially, yes.

Both buyer and seller deposit their security deposits and the bitcoin being traded to a 2-of-2 multi-sig escrow, where they each hold a single key. Once the fiat payment has been made by the buyer and confirmed by the seller, they both agree to release the bitcoin to the buyer, and to return both security deposits to the relevant parties. In the rare case of a dispute, there is a timelocked transaction signed by both parties on creation of the 2-of-2 escrow which sends all the coins to the Bisq DAO for arbitration, but it is very rare that this is implemented.

You can see why here: https://github.com/spesmilo/electrum/issues/7956. They are not used.

The Portuguese one is a good example - you'll notice it has 1626 words. This is the same number of words as old style Electrum seed phrases, which also used an English word list with 1626 words: https://github.com/spesmilo/electrum/blob/18cf546aab7d1a4d122a85ae2b49935cf64c9510/electrum/old_mnemonic.py#L31

Such phrases have not been used in many years, however.

No. They are a scam.

It is absolutely trivial for someone to create a fake wallet.dat file which appears to contains the keys to any address with any amount of bitcoin, which they then sell for a profit. Anyone who buys such a file will never be able to access the coins, because the private keys for them do not exist within that wallet file.

If someone really did have a real wallet which they had forgotten the password to, then they could use something like this to allow people to trustlessly try to crack the password in return for some portion of the coins. There is no need for them to sell their wallet file.

Did you read the link I provided above? https://learnmeabitcoin.com/beginners/outputs

Let me provide an example. Let's say your wallet has five unspent outputs or batches of coins in it. These are called UTXOs (unspent transaction outputs). Each of your five UTXOs contain 1 BTC each. You want to send 2.5 BTC to someone.

To be able to send 2.5 BTC, you must spend at least that amount. The smallest amount you can spend is 3 BTC, since you can only include an entire UTXO. So you include three of your UTXOs, which spends 3 BTC. Your wallet software will send 2.5 BTC to the other party, and will return 0.5 BTC (minus your transaction fee) to a fresh change address in your wallet. Your wallet will now have 2.5 BTC across three UTXOs - two of the original UTXOs which you haven't spent worth 1 BTC each, and a new UTXO worth 0.5 BTC.

Alternatively, you could spend 5 BTC by including all five of your UTXOs worth 1 BTC each. Your wallet would still send 2.5 BTC to other party, but this time would return the other 2.5 BTC (minus your transaction fee) to a fresh change address in your wallet as a single UTXO. You would still have 2.5 BTC left in your wallet, but it would be in a single UTXO rather than split across several UTXOs.

Think of each UTXO or batch like a physical bill or bank note. You can't cut a $10 bill in half in order to pay $5. You must hand over the full $10 bill and then receive a $5 bill back as change. If you wanted to give someone $30, you could give them three $10 bills and keep your other two $10 bills in your wallet, or you could hand them all five $10 bills and ask for a single $20 bill back as change.

I think this site might help to answer your questions here: https://gobittest.appspot.com/Address

It shows quite clearly the individual steps involved in moving from a private key, through a public key, and finally to an (uncompressed P2PKH) address.

To answer your specific questions above, you perform RIPEMD-160 on the output of a SHA-256 hash of your public key. You must then add an 0x00 network byte to the start of this result and the checksum to the end before encoding it as an address.

Here is a good link which explains the output model (or "batches") which bitcoin uses: https://learnmeabitcoin.com/beginners/outputs

You can do two things. You can either not spend all the outputs (batches) at once, and leave out the ones which are not needed. Or you can spend them all, and the left over value which you are not sending to the other party will be combined in to a new batch and sent back to your own wallet on a change address.

The output model is superior to the account model (such as used by Ethereum) from both a privacy and a fungibility point of view.

I think you have misread OP's question. He's asking what will happen if he spends more than he wants to, not less.

This has always been the case.

They are pretty vocal about the fact they are doing it. One example: https://nitter.net/HillebrandMax/status/1596785852478533632#m

And of course their Terms of Use explain quite clearly what you are signing up for by using Wasabi:

Emphasis mine. Sounds just like the terms of a centralized exchange. "We give your data to third parties, and we can do what we want with your coins without telling you why and there is nothing you can do about it".

And don't forget that Wasabi coinjoins are fundamentally broken and the devs either ignore the problem or outright lie about it: https://bitcointalk.org/index.php?topic=5419000.msg61220171#msg61220171

Again, that's not how it works.

If you import a non-English BIP39 seed phrase in to Electrum, it will show the error "Unknown wordlist". Because the wordlist is unknown, Electrum is unable to tell you if any of the words are incorrect or if the checksum is invalid. Since it is the words themselves which are fed in to PBKDF2, then if everything is correct then yes, you will still generate the same wallet. But you lose all the safety of unique words and a checksum, since these things cannot be checked without knowing the wordlist being used.

And, as always, Electrum have never offered any guarantee that they will continue to support BIP39 seed phrases.