There is no easy way to confirm a QR code itself is correct, and indeed, there exists malware which can change QR codes and display malicious ones with different encoded addresses. If you do use a QR code to scan an address (or transaction, or anything else), it is good practice to manually check the address which is then displayed in your wallet as discussed above before hitting sign/broadcast/confirm/whatever.

I very much doubt any newbies are typing addresses by hand, and especially not "most" newbies. As nc50lc has explained, typing an address by hand is very unlikely to lead to loss of funds due to the checksum built in to bitcoin addresses. Base58Check addresses have a 4 byte checksum, meaning that a typo only has a 1 in 4,294,967,296 chance of creating an incorrect but still valid address. Bech32 checksums are slightly different, since they are designed to identify the errors rather than just throw an invalid address error, but they also guarantee a failure rate of less than 1 in a billion.

This is a valid confirmation.

As it states, you have a "Good signature from Thomas Voegtlin." I can confirm that the key you have for him - 6694 D8DE 7BE8 EE56 31BE D950 2BD5 824B 7F94 70E6 - matches the key I have for him. You can also verify this here: https://github.com/spesmilo/electrum/blob/master/pubkeys/ThomasV.asc. The reason it tells you "WARNING: This key is not certified with a trusted signature!" is simply because you have not signed ThomasV's key with your own key to tell GPG that you trust it. This is not necessary, but if you wish to do this, then the commands you are looking for are gpg --edit-key and trust. You can read how to do so here: https://www.gnupg.org/gph/en/manual/x334.html.

You can. See my post here: https://bitcointalk.org/index.php?topic=5112334.msg49854683#msg49854683

For example, this link - https://bitcointalk.org/index.php?action=recent;boards=1,74,77,86,6,37,98,100,138,97,231,261,14,40,41,42,76,137,81,4,12;patrol - will show you all recent newbie posts from the boards in the "Bitcoin" section only.

You can also use this link to see newbie posts from all boards, but with bounty posts excluded: https://bitcointalk.org/index.php?action=recent;patrol;nobounty

I've never understood why we tell newbies, or anyone else for that matter, to only check a few characters of an address. Checking a few characters is not a foolproof way to protect against clipboard malware now, and it will become even less reliable as time goes on, malware becomes more complex, and vanity address generators become more efficient.

We tell people to spend hours learning how to verify software, read user guides, familiarize themselves with every aspect of bitcoin. We tell people to spend their money on hardware wallets. And then we tell them to save a few seconds by not checking the full address?

Here is what I do every time I make a transaction. It takes less than 10 seconds:

Maybe. Or maybe he was going to be depositing some money in his bank, sending it to a bitcoin exchange, and buying bitcoin with it anyway. Whether he does that with $100 or $10,000, it's still the same process, and so these extra steps are trivial for him. It also opens the possibility of people purchasing goods from him with bitcoin, and him sending that bitcoin directly to his supplier, meaning no intermediaries at all for him.

And also more centralized and less secure.

Again, your analogy is flawed because, as I stated above, the new smallest units and the old smallest units are not the same.

In your analogy I have quoted, the American gold had a larger supply and is less scarce than the European gold, sure. This would be the same as changing from 100 million sats per bitcoin to 100 billion sats per bitcoin. That would absolutely increase the supply and decrease the scarcity of bitcoin.

This is not what anyone is proposing. Creating more decimal points creates new, smaller units, (millisats) which may indeed be more shareable, but do not decrease the scarcity, as BlackHatCoiner has pointed out. It is analogous to comparing 100 million nanograms with 100 billion picograms.

What you saying would only make sense if the new smallest units (millisats) were worth the same as the old smallest units (sats), but they aren't.

If I split a gold ingot in to 1000 gold coins, there is the exact same amount of gold. I do not have any more to share than I did before, I have not increased the supply, and I have not made it less scarce.

If I split a bitcoin in to ten 0.1 outputs, one hundred 0.01 outputs, one million 100 sat outputs, one hundred million sats, or one hundred billion millisats, there is the exact same amount of bitcoin. I do not have any more to share than I did before, I have not increased the supply, and I have not made it less scarce.

Lightning already uses millisats. If people agreed with your point of view that this is equivalent to increasing the supply by 1000x, then the price should have tanked to $45 per BTC. This obviously hasn't happened, because dividing up sats in to millisats is not the same as raising the supply to 21 billion.

If you want to learn more about how scripts are written and the different opcodes used, then here are a few good resources.

I would start here - https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch06.asciidoc#transaction-scripts-and-script-language. This section of Mastering Bitcoin gives a good breakdown of simple scripts, and how things are pushed to the stack and executed.
The next chapter goes in to things in much more detail, including an example of a multi-sig script - https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch07.asciidoc.
You can see a list of all the opcodes currently used in the source code here: https://github.com/bitcoin/bitcoin/blob/fdd80b0a53b4af0b29cb6e03118e2456d053a757/src/script/script.h#L67
And this wiki page gives a nice summary of what all the different opcodes do: https://en.bitcoin.it/wiki/Script

From the script.

The first part of the script is the signatures, and the second part gives you the multi-sig requirements. Specifically, as follows:

4C - OP_PUSHDATA1
69 - Push 105 bytes
52 - OP_2
21 - Push 33 bytes
33 bytes of public key 1
21 - Push 33 bytes
33 bytes of public key 2
21 - Push 33 bytes
33 bytes of public key 3
53 - OP_3
AE - OP_CHECKMULTISIG

So we can see 2 signatures are required from the 3 public keys.

The terms can be a bit ambiguous at times.

Native segwit refers to P2WPKH addresses, which are in bech32 format and begin with bc1. Nested segwit refers to P2WPKH wrapped in P2SH addresses, which are in base58 format and begin with 3. "Segwit" can refer to either of these two subsets, or both of the subsets combined, depending on the context.

Maybe, but not necessarily. It is entirely possible to create a transaction with multiple different types of input. All it requires is either importing all the relevant private keys in to a single wallet to sign, or passing a partially signed transaction around for all the private key holders to sign their relevant inputs. The addresses may share a private key, but there is absolutely no requirement for them to do so.

You've got this backwards. Rather than seed phrases being generated by randomly picking words, 128 bits of random entropy (in the case of 12 word seed phrases) is generated, a checksum appended, and then encoded in to very specific words from the wordlist.

I'm not sure how you arrived at that number but it is incorrect. The actual number of valid 12 word BIP39 phrases is 2¹²⁸, or 3.4*10³⁸.

And as I pointed out, in OP's proposal he was still having to make a transaction to and from his special freezing address whenever he wanted to freeze or unfreeze the coins in his hot wallet, and he would be paying "next block" fees for these transactions too, meaning my multi-sig suggestion is no more expensive than his own proposal. I agree the fees are unnecessary and I would never do this, but it is not any more expensive than what he wanted to do anyway.

I agree, but the whole point of my multi-sig suggestion is that he doesn't need to unfreeze his entire stack at once as he would with his proposal. He can store, say, 5 BTC on his multi-sig wallet, move 0.1 to his hot wallet when he needs to spend it on the go, and return whatever he doesn't spend to his multi-sig at a later date.

Your entire analogy is flawed because the banana is not being made bigger. It is the same size, but being cut in to smaller pieces. If you add three more decimals to bitcoin, you have not increased the cap by 1000x. The new smallest units are a thousand times smaller then the old smallest units. There is the exact same amount of bitcoin in circulation as there was before, regardless of whether you consider it as 21 million bitcoin, 2,100 trillion sats, or 2.1 million trillion millisats.

If you add more decimals, you are cutting up the same amount of bitcoin/banana in to smaller pieces. Only if you raise the marketcap is the bitcoin/banana being made bigger and less scarce.

Satoshi talked about even moving the decimal point, let alone just adding more decimal places:

Are you trying to send bitcoin to your trading account, or withdraw bitcoin from your trading account?

The transaction you link to - 4324bd8c27015c653a43450854d6c92b69ef8d57606f0999c63c4d711a5142b0 - sends 0.00432384 BTC to the address you states belongs to you - 3LhZCEArqM2KsNGUKhqrC2rixojHMjda9Z. You say that transaction has not completed properly on your blockchain account despite having 500+ confirmations, yet 4 hours after that transaction there is another transaction - 307b64dc05b5bb3da119d26fe575b71c472126187eb8ff31bf75d83d57e767ce - which consolidates those 0.00432384 BTC with 99 other inputs in to one address which belongs to blockchain.com.

Not only has the transaction completed, but the coins have already been swept by blockchain.com. If your account is still showing the transaction as incomplete, then the only people who can help are blockchain.com support. Good luck - their support is absolutely atrocious, just like their wallet.

This can work well, provided you are smart about it. If you fund 5 wallets (for example) in the same transaction, then obviously they are linked. If you fund 5 brand new wallets with the same amount, with all the transactions in the same block, then that's probably linkable as well. You also have to be careful with depositing exactly 1.024 BTC to ChipMixer and then withdrawing exactly 4x 0.256 BTC chips, for example.

If I sent part of my main stash to ChipMixer over Tor, and then a number of days later sent an amount to one wallet, and then a different number of days later sent a different amount to a different wallet, and then maybe sent a bit more of my main stash to top up whatever I still had in ChipMixer, and then withdrew another different amount, and so on, and donated a few chips along the way, then it becomes near impossible to track.

Once you've done that, then every paper wallet is essentially an anonymous standalone wallet, and cannot be linked to you or any of your other wallets unless you make careless transactions or leak information another way.

Even if using one of the wallets discussed here, a user can choose not to burn their dust and receive it as change. There are also plenty of wallets which don't do this, and return the dust as change normally. There are also spammers which perform "dust attacks", sending out hundreds of thousands of dust outputs to try to deanonymize addresses when they are later consolidated.

One of my favorite ideas regarding dust, which unfortunately is not active, was Peter Todd's Dust-B-Gone. Everyone would sign a transaction spending all their dust, using SIGHASH_NONE and SIGHASH_ANYONECANPAY, and then send that transaction to Todd's server. Once he had a lot of transactions from a lot of different users, he would combine them all in to a single transaction which spent all the dust as fee and broadcast it. This effectively turned everyone's dust in to extra miner reward, while maintaining privacy and not linking two or more dust outputs together.

We each have a banana. We each cut our banana in to 10 pieces. I then cut each of those pieces in half, giving me 20 pieces. You buy a second banana and cut it in to 10 pieces too, giving you 20 pieces as well. I keep cutting my banana in to smaller and smaller pieces, whereas you keep buying more bananas. Only I have the same amount of banana as we started with, whereas you have increased the total amount of bananas.

Subdividing 21 million bitcoin in to smaller pieces is not the same as raising the cap of 21 million bitcoin, regardless of what units you are considering.

Sure. Here are some quotes from Satoshi regarding lost coins and population growth:

No, they wouldn't. The quantum computers currently being researched around the world are not even close to powerful enough to even consider attacking a bitcoin key pair. It will be decades yet before they pose any real threat.

Why would they? What would be their incentive to attack bitcoin and crypto in general? Cause millions of tech savvy users and thousands of major corporations around the world to lose a lot of money? Hardly a good business plan for a tech company.

Even if we assume there are 2.1 trillion 24-word BIP39 wallets with coins in them (as in, all 21 million bitcoin ever split up across 2.1 trillion wallets with only 1000 sats in each wallet), then you are still looking at a 1 in 5.5*10⁶⁴ chance of finding a collision. To find a single 10 character lowercase letter password is a 1 in 141,167,095,653,376 chance. The differences between these two numbers really cannot be overstated. That difference is comparable to the difference between a single atom and all the atoms in the entire world.

Using a passphrase of that strength is almost certainly going to be fine if your seed phrase is secured. But in our scenario here of a seed phrase which is known to an attacker, then it is simply not good enough. You are massively reducing your security.

In OP's initial proposal, he was suggesting having a second address which would control the frozen state of the primary address by way of sending special transactions to and from this second address. Given that, then the fees he would pay in my system are not significantly higher, and once taproot shrinks multi-sig transactions, won't be higher at all.

What script? Generating all the keys for a multi-sig wallet on the same device at the same time negates a large portion of the additional security that a multi-sig brings. Also, please tell me you didn't send all your coins to an unfamiliar wallet before first testing you knew how to spend from said wallet?