It isn't, such a setup is quite common. My node[1] is roughly about $10 a month and I have some spare capacity for my side projects. Something like this is usually dedicated for one purpose only so the argument is still valid that the average user doesn't find any benefits in taking the (fairly long) time to download just for a full node. I don't see how people would be motivated to do something like this if it doesn't benefit them directly. SPV clients are sufficient for most users and they probably wouldn't bother to even think about this.

RPis are actually fairly weak if you actually try them. I wouldn't do the IBD on it though.

[1] http://163.172.57.208/

---

Something that is related; for those who did this, is it reliable to use a USB SATA connection for this? I'm thinking of running another since I have a spare RPi4 but I'm not sure whether using an adapter would be okay,

It's far easier to get phished when you're using an online wallet. Electrum, by comparison is actively developed and new features are always added. Any security issue is always fixed fairly quickly; error from server displayed in rich text was mitigated by DOSing the older versions. Not really sure why would Blockchain.com even be in this discussion if anything they contribute to both the high fees and the congestion.

Not really alot of bad reports about Electrum in this aspect, as compared to Blockchain.com or that's from my experience. But okay, it's your choice. Let me know if you'd like to have another discussion on another topic. Any further discussion will make this off topic.

Okay. If that is your definition of competency, then so be it. Even if Blockchain.com is competent, it's just a matter of time till it gets hacked through one of its many attack vectors. I personally wouldn't choose a wallet that doesn't want to adopt opt-in RBF, correct fees estimation and general terrible UI. But yep, if track record is any indication, I would steer clear of them.

https://bitcointalk.org/index.php?topic=581411.0
https://www.forbes.com/sites/thomasbrewster/2015/02/24/blockchain-and-darknet-hacks-lead-to-epic-bitcoin-losses/?sh=27acdaef35e5

Then what makes you think that a wallet not implementing features that has been around for years is any good? Blockchain wallet might be safe but they're certainly not competent enough.

---

LN is certainly not the solution for capacity issues. Perhaps it can help to alleviate it but you still need onchain transactions for opening and closing channels. Given sufficient adoption, the network would still be congested with such transactions. LN can help in making day to day transactions easier as its way faster and cheaper but it can't solve the issue. Bitcoin's primary purpose is a speculative asset, not for people to use for day to day. If so, the growth in the price would have certainly been accompanied by an exponential increase in adoption which is obviously not the case. People wouldn't flock to alts, they are far more volatile and no one really cares about those kinds of transactions.

The mindset of people hodling kind of makes it unnecessary for people to choose any other coins.

Yes. I know, I said Satoshi's idea was 2-of-2.

No. Giving a third party that is trusted by both the full control of the coin is far safer than 2-of-2 multisig escrow. It's far more plausible for scammers to hold the coins hostage in this case as they'll have nothing to lose while the escrow is putting his reputation on the line. 2-of-3 could be better provided if the thirdparty is not colluding with either of them, if they are then self escrow would make it as good as a third party holding it.

Addresses do not expire. Payment requests are for record keeping only and is only local within that specific Electrum client. Addresses do not ever expire and the funds are still safe.

You'll be eliminating only the wallets that are not implementing RBF which are probably the ones you shouldn't use. It doesn't provide any clues beyond the fact that you're using a wallet that support RBF or that you're signalling RBF manually and using the wallet to sign it only.

There isn't any delay when you're transacting on exchanges because no Bitcoin transactions are executed on the exchange. It's simply just the exchange changing values within their database.

Bitcoin transactions are included in block that is mined by the miners approximately once every 10 minutes. That's where the delay comes in. Exchanges didn't solve this. If you were to withdraw your Bitcoins from an exchange, you'll be able to experience the delay with this. The extended delay comes with the transactions paying lower than appropriate fees. Instead of the transactions taking a long time, it would just be Bitcoin transactions becoming more expensive.

Electrum backups are not in zip files. It was probably archived as a zip file by the user. Do you happen to have 12 word phrases or seeds?

Try extracting it to a directory and finding files without any extension. You can try importing them into Electrum by selecting "Choose..." when it prompts you to create a new wallet and select the file that you think is from an older Electrum backup.

Most people actually don't receive Bitcoins in denominations that small or rather it's just not feasible right now.

It would be good if you could delay spending those small inputs. Instead, you can wait for them to accumulate and spend them all at once so it'll have loads of inputs and only one output. Spending it with a low fee would net you a confirmation sooner or later. During the weekends, the fees usually comes down to about 10satoshis per byte which would be fairly reasonable. I don't think Bitcoin would be affected by such an issue, the fees that you mentioned disincentives people to create transactions with small output as fees will eat into a bulk of it. Smaller transactions would be fine for lightning network however.

I'm not aware that Core uses Dandelion or that it was ever formally adopted. Bitcoin Core shouldn't be sending the addresses or any identifiable information to any other node anyways. Wasabi's primary privacy doesn't stem from it's enforcement of Tor but rather how it behaves as an SPV client.
Actually, here's one thing I don't get. Why do you need to add another output if you want to just send the transaction to yourself? It would simply lead to a larger transaction size and a much larger fee. If you want to "Cancel" your transaction, simply send the UTXOs used in that transaction to yourself and there isn't any need to add another UTXO. People would probably add UTXOs if they're trying to ensure that the output is of a specific size. Any MITM will result in the an adversary knowing that the transaction was broadcasted from that specific IP.

You'll have to do it yourself outside of the console. Bitcoin Core only displays the public key that corresponds to the address. There's no need for Bitcoin Core to display different versions of the address as it won't serve much purpose other than causing more confusion. It's not too difficult to do so.

It's more like a game theory in a sense. To reverse a transaction that is included in a block within a blockchain that is X blocks deep, an attacker has to build another blockchain from the block before that and include another transaction that is spending the same coins but is sent to another address instead. Now, since nodes only accept the blockchain with the largest PoW, the attacker has to effectively outpace the rest of the network and be able to mine X + 1 block. Remember that the rest of the network is also mining at the same time and lengthening the blockchain. As such, it is both prohibitively expensive as well as unprofitable to do so.

Consensus is an important aspect with any distributed systems. The concept is difficult to explain if you don't understand the workings of Bitcoin. It'll be great if you could skim through the whitepaper and clarify if you don't understand anything.

https://bitcoin.org/bitcoin.pdf

Nodes will always want to follow the chain with the largest proof of work. By doing so, it ensures that an attacker cannot broadcast a different chain with a significantly lower Proof Of Work (ie. Much lesser efforts) that replaces the transactions in the chain with the largest PoW.

Timestamps are not followed strictly within Bitcoin and there is a fairly big deviation allowed from the median time. I'm not really sure what you mean by tracing the divergence or how it'll help in this case?

Edit: Satoshi actually explained the gist of how the network works in his white paper. I think your confusion lies within how the network functions rather than on PoW itself.

Nope. Proof Of Work is essential in making Bitcoin work in the first place. It acts as a consensus mechanism among nodes to decide which are the transactions to be accepting and considered as valid. It builds the blockchain and provides security to the transactions that are included in the blocks; as the confirmation increases, so does the security as it is the amount of work that an adversary has to do in order to reverse those blocks.

Without a system like that, someone can just broadcast two different transactions spending the same coins. Which transaction should the node then consider to be valid? How does every node on the network consider that transaction valid and not the other transaction? In Bitcoin, transactions are thus included in blocks and the nodes will always follow the blockchain with the largest cumulative proof of work. This ensures that the same coins are never spent twice and all of the nodes will recognize the same set of transactions as valid.

Perhaps, it can be better. It still fulfilled its primary purpose to help you get a confirmation within X blocks. I'd rather them overestimate the fees at times rather than underestimating them. Imagine taking the estimate for 2 blocks and it ends up taking a few hours for most of the time if it takes a more conservative estimate.

If the server can't give you the correct mempool estimation, then it isn't reliable to be used as a server. You might not even see your own unconfirmed transaction if the server is that inaccurate. There is a fairly decent allowable margin of error for mempool estimations and not seeing a few transactions should be fine. Comparing the mempool of my nodes, there is only a slight discrepancy of roughly about ~1% with the transactions at a lower fee rate. Higher fees transactions are generally fairly well propagated so that's really not an issue.

But it is a valid point of course.

Paper is from 7 years ago. The paper highlights the risk of sybil attack over Tor and poisoning by exit nodes which isn't possible if you're only use onion nodes which doesn't route the traffic through exit nodes. I'm not sure why people keeps on citing it.
What wallet are you using? It would be far better for you to do a single connection to your full node if you're using an SPV wallet. Most SPV wallets are not great at preserving privacy. If your wallet is using bloom filters, you need to configure your node for it as well.

If it's a wallet.dat file or something similar, then Dave from walletrecoveryservices would probably be your best bet. You won't have to send over the entire file but just the relevant data of the password.

There is no such thing as a wrong estimation, unless you're telling me that your transaction doesn't get a confirmation within the ETA. Would it be bad to be overpaying for fees if you're almost always going to get a confirmation within the timeframe as stated (within X blocks)? Probably not. Overpaying for your fees is just a feature of Electrum's (and Bitcoin Core's) fees estimation system.

Is there really a need to go to various sources for just the mempool stats? I mean there is bound to be deviation from various different mempool but its somewhat consistent as long as you're aiming for the top few MB or so. Electrum's mempool estimation (within 0.5vMB, etc) is accurate enough and checking mempool sites would give you roughly the same results, probably easier than reading graphs or navigating around the other sites.

It's actually quite dependent on your wallet as well actually. If you're using wallets like Bitcoin Core or Wasabi then probably not. Bitcoin Core doesn't query someone else for your transactions and Wasabi does not leak identifiable details as well.

In the case above, unless someone had a deliberate MITM between your connection to the other nodes, they wouldn't see the transaction being broadcasted from your node or at least with fairly little certainty that it was broadcasted from your IP.

Tl;dr: RBF to your own address leaks the same level of privacy as with your other transactions since you're only sending the funds back to yourself. The greater concern would be to use SPV wallets without proper privacy measures.