None. The wallet.dat is sufficient enough for you to restore the entire wallet since the seed is inside it. Besides, the seed can change when you change your password; you would have to update your seed everytime you do that.

The only possible advantage that I could think of is if you keep a physical copy of the seed. As with any other backing up, keeping a physical backup would be the best way to protect against potential hardware failures. Physical backup is pretty redundant if you keep more than 2 backups on different storage media.

It really depends on what you mean. There's two scenarios:
If two person import the key into their own Bitcoin Core client, the address will still be in their wallet when they change the password.

If the two person have the same wallet file and they change the password, the future addresses generated on both of the wallet files will be different.

In short, the password change will not affect the addresses that you already have. Only the addresses generated in the future will be different. That's why it's recommended to renew your backups with every password change.

No. Each wallet file is encrypted separately. Encrypting one file will not change the other file at all.

It's worth noting that the keypool for your wallet will be refreshed once the password is changed. For HD wallet, the HD seed of the client will also be changed. Thus, from that point on, the wallet files will generate completely different keys. Every time you update your wallet file, you have to replace all your backups. This is mostly to prevent future attacks if your past wallet files aren't stored properly.

You cannot send a "fake" Bitcoin transaction that you have. Majority of the network runs the reference client which also follows the protocol rules. With that in mind, the nodes will reject and refuse to propagate any transaction that doesn't follow its rules. The main rules is that the transaction must have a valid signature which would provide the proof that the UTXOs are authorised to be spent. In addition, its also not possible to fabricate a transaction with fake inputs since the inputs must be in the UTXO list of the individual nodes.

Add the contents inside the bitcoin.conf but without the numbers and the spaces before the "fallbackfees".

The only code you should include is:

Is there a problem with using a custom fee? It would be less complicated if you were to set your own custom fee in the other field.

Signing a message means that both the sender and the receiver will sign a message respectively using their ECDSA private key. For example, if they sign a message stating:
"XX is in control of ADDRESS", you will know that XX has the private key since it won't validate unless it has been signed with the private key that corresponds to the address. Thus, you will be able to tell if the transaction has really occurred if there is a transaction between the two addresses.

---

Address reuse is not bad, per se but it would decrease on their privacy. It is advisable for the seller to be able to generate a separate address for each transaction anyways. If all else fails, you can ask the seller to get the buyer to send Bitcoins at specific amounts, (0.00201928 vs 0.00201900) for example. The downside is that the seller has to update you about the amount of Bitcoins that will be sent by each buyer.

The dust output means that your transaction contains outputs with amounts that is below the dust threshold. The current dust threshold as per the reference client is 546 satoshis. The network intentionally do not allow transactions with outputs that is too low to avoid users inflating the size of UTXO and/or the blockchain and outputs with such a small amount are usually fairly useless.

I'm fairly sure Electrum avoids this and absorbs the change into the fees if it detects that the change is dust. Are you sending someone dust?

IIRC, there was a case whereby someone was scammed with a fake seed. The person bought a hardware wallet online advertised as new and there was a pregenerated seed that was disguised as the recovery code and several victims fell for it. I would still take precautions and do my own due diligence with regards to buying a hardware wallet regardless of whether its new or not.

On the topic of raspberry pi, that's my current cold storage solution. Using Core on even with Pi 3+ is possible, provided that you're not operating it as a full node. I prefer a more simplistic approach with Electrum's GUI and its worth a consideration since the whole setup goes for about $35 and its cheaper than even a used hardware wallet. The security would be somewhat similar barring physical attacks.

No. There's a reason why they go through the hassle of selling you the hash power. For most of the sites, they are a scam; either a ponzi or an outright scam. There's plenty of examples about this, hashie bring an example.

For those who are at least legit, they purchase and host the hardware and they sell the hash power in small denomination. It doesn't mean that the hash power actually belongs to you, it's just that they are paying you what you would've mined if you had that much hash power. They often charge exorbitant fees for the maintainence fee and overcharge in other aspects to make up for the potential loss. Since the network is usually volatile in the past with regards to the difficulty increment, there were cases whereby people actually made money from it. However, the margin of profit is too low for it to be sustainable nowadays. The only legitimate cloud mining company I know is cex.io but they've closed their cloud mining department and focused on other stuff.

If you're thinking of trying out cloud mining, I strongly advice you against it. If its actually a guaranteed profit, the companies would just mine for themselves. Even if its profitable, the margin would be so small that it would've been more worthwhile purchasing Bitcoins directly.

That's true. You still need to parse the transaction to compare them to your own mempool. The idea is that the miner mines an empty block while validating the new block simultaneously.

SPV mining was fairly common in the past and that is also what caused the fork in 2015[1]. Miners would connect to each other's pool and obtain the hash of the newly generated block. Since they don't have the full block yet, they would only construct an empty block with the coinbase transaction so as to avoid mining an invalid block. It has caused quite a few problems and it was a fairly controversial issue at that time.

No matter what happens, the overheads with the propagation of blocks still exist. Even with the much faster internet speeds and the improved verification of blocks, miners would still waste some time trying to validate it. Since it wouldn't actually be that much of a hassle to implement SPV mining, miners would still do it.

[1] https://bitcoin.org/en/alert/2015-07-04-spv-mining

No. The transaction ID is a alphanumberical string which is 64 characters long. The transaction ID is unique to every transaction and it should appear in with the details of your transaction in your wallet.

You can also use your address to get your transaction ID by going to a block explorer and searching for your address. You should be able to see the transaction that you've sent, along with the transaction ID.

Are you using the same ports (8333) on both of the clients?

This is just a hypothesis since I've never tried it before: If you're running them on the same port with the same public IP, both of your nodes are receiving the same information from the same 12 incoming nodes. Since the information are mirrored to both of the nodes, it is likely that there is a conflict and your other node is rejecting the connection from the extra nodes. Try checking the IPs connected to each of your nodes.

Nevermind, I thought about it further and realised that the nature of TCP wouldn't let 2 programs to be binded to the same port and routers wouldn't have allowed this with port forwarding anyways.

Loan is repaid. TXID:d8cc5c4cdde9062c8b958f2149dfac17f0b61014685612c3939db872d17eeec6

Personally, I wouldn't be that paranoid about it. If you have a government that can keep you in jail indefinitely just to get your Bitcoins, then you have much more to worry about. It's not exactly difficult to hide a wallet.dat either, search up steganography though it does have certain downsides to it but it should be a good enough obfuscation method.
To be fair, even Bitcoin Core uses HD wallets as a format to store Bitcoin. I think it would be more convenient and secure this way as the necessary frequent backups meant that unsecured old backups could be lying around anywhere.
As long as you are able to get the transaction information, you don't need to keep the client itself synchronized. There are ways to obtain the UTXO of a transaction, though it might be slightly more inconvenient.

This shouldn't be a question. The payload can consist of more than the clipboard malware by itself. Removing the virus doesn't guarantee that the other undetected malware would be gone too.

It isn't that much of a hassle to just get a new wallet on a separate computer and wipe the current computer after backing it up. You can't be too safe.

This is changed quite sometime ago with the introduction of HD wallet. While the wallet can still be run in the legacy mode without the HD function, it is even more dangerous with it being HD. Once the seed is compromised, the seed will remain the same for as long as you keep using the same wallet.dat file or your password is changed.

Just a question, why can't the Ledger be shipped to other countries? I'm pretty interested in participating but its limited to US residents only.

It will require a hard fork as it won't be backward compatible.
Transactions are only rejected from mempool if they are invalid. Due to the limited space of the mempool, nodes usually exclude transactions after a relatively long period of time. In the case that it happens, the transaction won't become invalid; simply rebroadcast the raw transaction and it would be back in the mempool.

Lot C @ 0.028BTC
Lot D @ 0.011BTC

There's nothing wrong with the transaction. It went through perfectly fine and the funds were transferred. The problem isn't with your transaction but its with your site. You have to contact your online wallet regarding that.