UTXO doesn't get returned. Change is returned to a change address within your wallet.

Using heuristics to determine the wallet owner or whoever it is associated with is fundamentally flawed. They guess the sites that the addresses belongs to by analyzing the transaction paths, for e.g. consolidating them into a single address used by a known service. Mimicking certain behavior of wallets or exchange can mislead the websites into grouping it into the same category as those services. I would take the results with a grain of salt.

From the amount being specified. The command accepts a floating fee with the confirmation target parameter or your own set fees. That is true for 0.21.0. Anything earlier than that doesn't expect a txfee being specified in the command itself, only the confirmation target.

If you set subtract fee from amount, the amount sent to the user is 1BTC - fees. Otherwise, it maintains the 1BTC as the amount and subtracts the fees from your other outputs/change instead.

Not with sendtoaddress, AFAIK. You can make your own rawtx for the purpose.

As far as possible, try to check the addresses on both your main and offline instances; just the first and last few characters will be sufficient.

Master public key will provide zero deviation from both your wallets provided the same parameters but as I have mentioned, nothing can stop a malware on your online computer to change the addresses on it. The addresses that is displayed on your cold wallet will always be correct, but there are still quite a few attack vectors present on your online computer. I'm not sure if I'm being overly concerned about this or not.

You might need to increase the gap limit on your offline computer if someday you don't see the addresses being displayed on your offline computer.

That is how some spy nodes operate. Simply by trying to connect to as many nodes as possible for the purpose of deanonymizing them.
You can... Assuming that you actually can do something with that information.

By and large, transactions has no effect on Bitcoin price or at least having immediate knowledge would have had zero difference. It would be good if you could state something that actually affected Bitcoin's price and was advantages to someone who had that information 8 seconds before the others.
Because most of the people have zero use for it. They're just wasting extra resources for something that is so trivial to them. They don't want to saturate their bandwidth and resources by having to respond to every message that their 10,000 nodes send.

Besides, I probably wouldn't recommend anyone to connect to 10,000 nodes. There reaches a point where your node either runs out of resources or starts to have significantly diminishing benefits to that.

The others are all answered well except for this. Generally, it is okay for someone to assume that the address corresponds to the one that you control. That is, assuming nothing is actively changing the address you're seeing and/or your clipboard. I would assume the worst and attempt to cross-check the address on my cold wallet as well, just a simple validation to check if I'm really sending to the correct address.

The purpose of your online wallet is to check for balance as well as to create a transaction. There is no protection if you've downloaded a malicious version on your online computer or if a malware can change the addresses in your online Electrum instance.

It is not milliseconds in terms of the total time for propagation. It is the milliseconds of difference.
The network is quite robust and there is little to no resource strains when we're met with higher transaction rates;  mempool would simply start to reject lower fees transactions in favour of those that has a higher fee rates. Transactions are fairly small in the first place, so there is nothing with regards to that. There has never been any connection problems within the network, it is extremely robust.

It is simply pointless for you to whitelist nodes, you're giving up the builtin DOS protection as well as your privacy as you're having no delays with transaction relaying. What you want to do, is to establish a direct route to the miners as they're ultimately the ones that decide whether your transaction gets included in their blocks or not. Having faster propagation within the node would only be somewhat faster if your exchange or whoever you're sending to actually cares about unconfirmed transactions, which is pretty much never the case.

Preferred peers are whitelisted peers or outbound peers. I believe the reverse would be simply just inbound peers, makes sense as the purpose of doing so is to enhance the privacy.

Good point. But again, OPAC blocks by Marathon was an experiment that backfired catastrophically so I don't expect people to start openly following that route.

If we were to define coins that way, then we're going to label even the new coins as being tainted (albeit to different extent). Block rewards are considered as a single unit as the fees. It would just be ridiculous to assume that the miners were intentionally laundering the Bitcoins as well. If exchanges were to also label taint on newly mined coins, then it wouldn't make sense at all. If we get to a point where a majority proportion of the coins are "tainted", then Bitcoin is just not fungible anymore or everyone would just give up on the concept.

Both will propagate to a similar extent and be seen by a miner. The premise of a faster propagation comes with the fact that your peers must not be spying nodes and are not interconnected to a huge extent. It does nothing if you're going to relay to nodes that are mostly interconnected to each other; you might as well just propagate to a few nodes and they'll probably achieve roughly the same rate as well. There is no reason to assume that sending your transactions to more nodes would bring about a faster confirmation as the time it takes for it to be propagated to half of the network stands at 3s in 2017, as seen in a research paper.

So long that you can propagate the transaction to a miner within a reasonable period of time, there is no reason to believe that your transaction will always get confirmed slower. There are still various delays even when it reaches the miners; validating your transaction, pushing your transaction to the miners in the pool, (re)assembling the block headers. The inherent delay would already lower the significance of having 1-2 second advantage over the others. Unconfirmed transactions don't mean much to most exchanges anyways.

In your Electrum transaction details (right click>View Transaction), the two outputs should be colour coded. One of them is Yellow in colour and that should be your change address.

If that is the case, then there is nothing to worry about. Electrum sends the transaction to a different address for the change.

Correct. The device actually cannot check for hardware modifications by itself. The most that it can do is to verify that the firmware is authentic and there is nothing done to it. With the PCB, you can embed certain stuff and trick the user into thinking that the device is unmodified. That is why hardware wallets also have tamper-proof mechanism and people are strongly discouraged from purchasing used HW wallets.

With regards to OP's question, the MCU and the firmware is designed to not leak sensitive information via the USB and the bootloader should validate for the authenticity of the firmware as well. There is nothing against exploitation of vulnerabilities though, Trezor does have quite a serious vulnerability with their devices which allows seeds to be readily extracted. Hardware wallets are far more hardened than your regular computer but that doesn't mean it is immutable to exploits.

They aren't really considered taint, or at least the known transactions that exchanges has openly restricted so far. Exchanges only ban them as a result of a direct link between the deposit transaction and something against their ToS. Definition of taint is generally recognized as something that can be linked to certain illicit transactions but that is not what (most) exchanges actually ban. CoinJoin and gambling sites are not illegal per se, but it is against their ToS. You have a strong case against the exchange denying you service if you're able to prove that you're not involved in any activities against their ToS. Their definition of taint is different from how we define it.

The best way to remove taint is to cooperate with a miner and launder it through the transaction fees. Most blockchain analysis don't follow that trail for their taint.

Yeah, that is going to be quite a long wait. There are at least 17vMB of transactions paying a higher fee rate than you and would take 17 blocks to clear them alone.

Problem with CoinJoin is that once the transaction appears on the blockchain, it is difficult to do anything to it. Using RBF requires the agreement of all the users for which I don't think Wasabi provides. You can do a CPFP on that transaction which also means that you're paying a much higher fee as you're in effect making a fee increment for everyone for which you won't get any compensation for.

Question of whether Bitcoin is hackable is quite difficult to answer. Yes, there are ways to reduce the complexity to crack an address but it is mathematically still implausible currently due to the amount of resources required.

It is the kind of questions that you won't really know the answer to. Has Bitcoin been hacked? Perhaps, there is no way to prove a negative and arguably difficult to prove a positive in practice. Of course, the theoretical aspect of this puts this at a ridiculously miniscule chances if you use Bitcoin correctly. If you did put your keys on a server that can be accessible by a third party, then it is perfectly possible to get compromised.

Won't work. The site restricts connections from Tor exit nodes or through its onion address, no matter what UA it is using. It would be quite bad for the site if they're restricting you based on your UA instead of your IP. API calls don't consume more bandwidth or resources to pose a problem.

The best way is to synchronize your Bitcoin Core fully and cycle through your various wallet.dat. This is extremely time consuming but is practically the only way for you to ascertain the balance in each of your wallet.dat.

You can of course, export your data using dumpwallet command but you'll receive thousands of addresses and it would be even more time consuming to filter through them. The addresses are organized in rows so you can have a script to call some blockexplorers for their balance but that can only be fast if your block explorer doesn't rate limit you.

Your cold wallet should contain the private keys, or else you won't be able to generate any addresses in the first place.

Generate your cold storage wallet as per usual, with createwallet. Afterwards;


You'll get a string and that is your descriptor.

If you want a watch-only wallet, it has to be online, there is no point keeping it offline. You have to generate a descriptorwallet first;

Afterwards, import your descriptor through this, check the syntax here[1].

[1] https://bitcoincore.org/en/doc/0.21.0/rpc/wallet/importdescriptors/

Looks alright to me. During startup, Core checks the last X blocks for inconsistencies. Specifically, the debug.log prints that they've checked the last X blocks for coin database inconsistencies.

I don't think it does a full check of the entire chainstate, as it'll take too much time. Do CMIIW.

The last time I checked, Bitcoin Core shuts down gracefully upon running out of disk space so not really a lot of concern for any corruption there. Even if there is, it wouldn't be a big issue, just replace your data.

The leveldb should have CRC32 checksum for the records and would throw an error upon a mismatch.