That's expected behavior. The feature is not yet implemented as there is a prerequisite refactor that has not been merged yet.

A couple of these losses have occurred relatively recently. This stackexchange post enumerates many of the instances where miners failed to claim their full reward, with the most recent occurring in 2018.

The only way to know is to see the software that produced these strings. What software did you use? These are not things that Bitcoin Core produces.

Are the transactions you are looking at unconfirmed? It is only "yes" for unconfirmed transactions as only unconfirmed transactions can be replaced.

That is incorrect. "3" would to correspond witness v17, however BIP 141 states that the highest witness version is 16. This corresponds to OP_0 through OP_16 - there is no 17 or greater.

No. Segwit v1+ outputs use bech32m (defined in BIP 350), so the correct address to use will be slightly different at the end (the checksum is computed slightly differently in bech32m).

Because segwit v2+ are not yet defined, these outputs are anyonecanspend outputs. They can be spent in the same way that b10c007c60e14f9d087e0291d4d0c7869697c6681d979c6639dbd960792b4d41 spends segwit v1 inputs prior to taproot's activation.

They only don't accept them because addresses that encode segwit v1+ scripts must use bech32m. Otherwise these addresses would be accepted as BIP 173 states "implementations MUST allow the use of any version" so that older wallets can still send to new segwit versions when they are deployed.

Instead of copying the wallet.dat file, use File > Backup Wallet. It will guarantee the wallet is in a consistent state.

If you are using the RPC, you can use the backupwallet RPC.

---

This is likely because BDB doesn't actually write everything to the wallet.dat file when a write completes. It instead writes it to a log file, which is later compacted into the wallet.dat file periodically. If you copy a wallet.dat file while it is in use, it is likely that you are simply missing the log files and so missing data.

It is always risky to copy because it writes to a log rather than to the data file.

The wallet.dat file is not directly locked. IIRC there were problems with doing that.

---

If OP is using a descriptor wallet, then the database is actually a SQLite database and not BDB. There are thus much better guarantees of consistency. SQLite uses a rollback journal instead of a log, so data is only not in the data file for a short period of time (whereas in BDB it can live in the log for a very long time). Even so, if you were to copy the wallet.dat file in the middle of a write, there would still be consistency problems. Again, the best way to backup your wallet is to use the built in backup functionality as it guarantees the database is consistent before making the backup.

Pruning is not enabled by default. It will not suddenly enable pruning unless you have done something abnormal. If you run bitcoin-qt and it detects that it is the first time it is being run (the GUI settings file could not be found), then the welcome dialog will default to pruning on. But that can be disabled, you just need to uncheck the box. That is the only time pruning is enabled by default.

Regarding fees, the fee estimator requires being online for some time before it becomes accurate. It needs to observe transactions entering the mempool and subsequently being removed from it as blocks are being found. If you are starting it up and then immediately making a transaction, the estimator won't have any data to estimate fees so it isn't going to be accurate and instead default to the minimum.

The order is that way because 0.20.2 and 0.21.2 were released after 22.0. There will still be minor releases for some older versions. These include bug and security fixes.

Public keys are elliptic curve points, not scalars. You can't just multiple x and y by 2. You need to do elliptic curve point multiplication, which is non-trivial. Wikipedia has an entry on elliptic curve point multiplication, you should start there.

No, Taproot does not hide the amounts nor the Taproot output key itself. It is still obviously a Taproot output and the address can be known.

What Taproot does allow for is to hide any scripts. Taproot conveys privacy in that exact scripts do not have to be revealed. Furthermore, Taproot introduces the idea of the cooperative case where all parties involved in a script agree with what to do. In that case, it is possible for a spend of the Taproot output to appear exactly the same as a single key Taproot spend.

A simple example of this is multisigs. Currently, if you have a multisig, when it is spent, it is obviously a multisig. All of the public keys involved can be seen by everyone. The signatures of those that signed call also been publicly viewed. But with Taproot, if a key aggregation scheme like MuSig were used the resulting spend would look just like any single key Taproot spend. This is where privacy is conveyed.

Segwit changed the data structure, taproot does not. This change is specified in BIP 144.

Given that Bitcoin doesn't have confidential transactions, no, they aren't wrong.

They absolutely are as scripts are the most vital part of a UTXO. The script is what determines who is allowed to spend the UTXO.

A UTXO is identified by the txid of the transaction it was created in, and the 0-based index of its position in the transaction's outputs array. That txid is prev_hash, and the position is prev_index. This applies to all Bitcoin transactions, it is not specific to trezor.

It's stored in basically the same way Bitcoin stores UTXOs - the prevout with the corresponding script and blinded assets and values. This is taken directly from the transactions.

Fees are explicit. They are put in an output with an empty output script. The value of a fee output is not blinded. As fee outputs are special, they don't go into the UTXO set.

You don't explain why that would be the case.

If I were a new node, how do I know that the transactions I receive are real transactions? How do I know that the coins being spent are valid? Without a transaction history, how do I know that coins aren't being created out of thin air? There is more to validation than just double spend protection.

It is possible. Transaction malleability allows a third party to create a transaction that is technically a conflict (and thus double spend) of the original. The same outputs are being created, and the same inputs are being spent, but the scripts in those inputs are different yet still valid.

So what about new nodes? How does the information that those inputs are now unspendable get to nodes that weren't around at the time of the double spend? If you sync and are just told that "these inputs are unspendable", what is the proof that those inputs should be unspendable?

Wallet software is way more obvious than a PSBT. And wallet software will contain far more private information than a PSBT.

PSBTs are just base64 strings, you wouldn't know that it is Bitcoin related unless you are looking for it specifically.

And again, you can just encrypt the PSBT with a third party tool. Then it will look like an encrypted file, instead of specifically an encrypted PSBT as adding an encryption standard would make.

Almost all of the information contained in the PSBT is (or will be) public information. UTXOs are public, signatures are public, txids and vouts are public. The only thing that is not public are the BIP 32 derivation paths, and those aren't particularly useful to an attacker.

What "personal information" are you concerned about? What is the attack you are concerned about? If you are transmitting PSBTs over the internet, then you can employ third party tools for encryption, such as PGP. If you are concerned about a man in the middle between local machines, then you are concerned about an attacker who has gained remote access to your machines, in which case you have much bigger problems.

When you unlock the wallet, the password is used to decrypt the key actually used to encrypt the private keys. That decryption key is stored in the wallet as vMasterKey. It will remain there in memory (and thus the wallet is unlocked) until CWallet::Lock is called to remove it from memory and thus lock the wallet.

When you use the walletpassphrase RPC, a timer thread will be scheduled to run after the given timeout. That thread will just call CWallet::Lock and lock the wallet.

The GUI doesn't need a timer like the RPC does because it can ask for the passphrase when needed, and lock the wallet when it is done with what it is doing. So it does not have a timeout in the same way the RPC does. Rather each action that needs the wallet to be unlocked for it to succeed will create a WalletModel::UnlockContext object, which in doing so, will spawn the AskPassphraseDialog to get your passphrase. That sets CWallet::vMasterKey thereby unlocking your wallet. The UnlockContext object has a destructor which calls CWallet::Lock so when it is destroyed, the wallet is locked. The object is destroyed when it goes out of scope, i.e. when the action being performed that needed the wallet to be unlocked is completed.

You should verify the signatures file.

You can also compare these against what every builder in the build process got: https://github.com/bitcoin-core/guix.sigs/tree/main/22.0 (they should all match) and verify the signatures on those SHA256SUMS files too.