I've been experiencing this problem on every initialization since I built a new computer with completely new hardware and great specs. It cannot be a hardware limitation, the resource usage by Bitcoin Core is barely noticeable at all. The synchronization proceeds without any issues according to the debug.log so it's purely due to the GUI.

I went on to research about this at that time and it seems like it has been an issue with the GUI for quite some time: https://github.com/bitcoin/bitcoin/issues/17145. Probably doesn't require an issue raised on github, was mentioned half a month ago.

Yes you can. You can use whichever transfer medium that you need as long as the raw transaction gets transferred between the online and offline computer.

Electrum supports QR codes natively, if you have a camera you can use it to transfer the raw TXes as well.

Tails comes with Electrum pre-bundled but you'd have to have persistent storage to update the Electrum to the latest version which would be necessary if its connected to the internet, perhaps not so much if its used as an offline wallet. In terms of security, I don't think they would differ too much. You'll still have to download and verify the Electrum instance (for Tails would be the OS itself).

Tails would be pretty quick and easy to set up as compared to setting up your own Linux instance and install Electrum. Keep in mind that Tails is just like a modified Debian.

There are authenticator apps on PC but that doesn't mean you should use it. It puts you at the risks of having malware stealing your OTPs with the authenticator apps being on the same PC used to access the account. The authentication should be done with a separate device that you own.

They use different Tor identities for each connection with BIP158 filtering as mentioned prior to that. Their docs actually has a comprehensive overview of it[1]. Using a privacy-centric wallet is far better than using a wallet that doesn't do anything for it's privacy and attempting to modify it to enhance it's privacy; Electrum is just not for privacy. I'm not exactly sure how the communication between the server as well as the Electrum client operates, perhaps someone can shed some light as to whether Electrum does transmit anything that could identify specific Electrum instances?


[1] https://docs.wasabiwallet.io/why-wasabi/NetworkLevelPrivacy.html#full-node-by-default-block-filters-over-tor

P2SH does not have to be Segwit, nested Segwit is just a subset of P2SH. It is just an address that has special unlocking scripts, multisig time lock addresses are examples of them. That's also why Jlopp has a parameter for the number of signatures.

Yes. It doesn't matter if the mixers are traceable or not. The reason why exchanges suspend accounts associated with CoinJoin because they are really easy to tell.

ChipMixer's chips are obvious as well, but not as obvious as CoinJoin transactions. Having a transaction with a nicely rounded input with previous transaction being used to split them into individual UTXOs of similar amounts doesn't necessarily mean that it is from ChipMixer. CoinJoin transactions are very obvious; many inputs and many outputs with some of them being the same size. Exchange wouldn't suspend you for sending from or to a ChipMixer address, they can't tell with absolute certainty that it is from ChipMixer. As an exchange, you would rather err on the side of caution and not point fingers at things that you can't be absolutely sure about.

You probably have to choose it carefully. If you accidentally choose the wrong kinds of address, those associated with more of an illicit activities, it could be used against you though I highly doubt so. You probably have to choose a huge pool of addresses to be able to hide your own addresses within them and that could lead to a degraded experience when using it. If your primary purpose is to just see if there are any transactions which are related to your address, just use blockexplorers with Tor.
That is something like Bloom filters I suppose. The caveat is that the Electrum servers does have some limitations and could result in a significant slow down if you make too many queries. It doesn't help that the solution would only work when you're querying addresses and not when you're sending any transaction.

If I may ask, would you consider Wasabi Wallet instead? That will be more suitable for the purpose.

It is easy. Most of the malwares prey on the user's negligence to steal the funds. Putting your Bitcoins on an exchange doesn't mean that it is impossible for the attacker to be able to steal your coins. The additional attack vector on the exchange part would make it much more risky. 2FA does not completely mitigate the social engineering attacks, malware attacks, etc.
Common misconception. 2FA is just an additional layer of security if your password gets leaked and stuff like that. If the exchange doesn't explicitly display the transaction information on a secondary device for the user to check, it is possible for the attacker to just replace your address with theirs and use your 2FA codes to transfer your funds.

By putting your funds on an exchange, they also have the ability to freeze your accounts for whatever reason they can spin up.

Electrum isn't very centered around privacy so you will find it hard to do anything with it. Confusing the server with multiple addresses can be fairly inefficient and would be ineffective if the transactions would be broadcasted through it anyways.

Manually changing the Tor circuit could work but doesn't solve it being more resource intensive, depending on how many addresses you want to hide it in. I'm thinking that you're wanting to mimic the behavior of Wasabi wallet, so I'd say just going to it would solve the issue and make your life easier. If you insist on using Electrum, you can probably get better privacy by running an Electrum private server on a RPi or an old computer.

Slightly larger than Segwit to Segwit by about 3 bytes. When comparing legacy and Bech32 addresses in the scriptpubkey, you'll notice the difference.

ScriptPubkey of bech32 output: OP_0 ....
ScriptPubkey of P2PKH (legacy): OP_Dup OP_Hash160 ... OP_Equalverify OP_Checksig
Same logic. Smaller than legacy to legacy by 3 bytes.

I was going to suggest something like this. But I was thinking that doing a CoinJoin with yourself is unnecessary, making the transaction larger than needed and creating more UTXOs (perhaps bigger but still more than necessary) to be consolidated in the future. It doesn't exactly break the connection or obfuscate it, I'd say that having a CoinJoin with multiple entities would probably be more useful.

It does give some extra privacy but doubt it helps that much.

Bech32 will help you save on the fees, more than the other address types but you'd probably find that if you consolidate your funds regularly, the effects would be compounded. If you want privacy, you'd have to go through a mixer or CoinJoin to break the connection. All of the Bitcoin address types will provide the same amount of privacy, if you use them the same way.

Yes. Which is why we don't enforce Bitcoin to be on Tor only! Running node on Tor doesn't single you out, I do not understand what you're trying to get here. Running a node on Tor will not allow anyone to identify your IP, conversely, running it on Tor will obfuscate your privacy sufficiently. Running a node on Tor would definitely be more secure than you running a node on the internet, running a node on Tor will not allow your ISP or whoever identify that you are running it, connections are encrypted from point to point.


Yes. So do you understand that the paper that you've linked is about MITM which is also relevant to dVPNs and poses a security risk, perhaps even more so than your VPN provider or ISP and arguably less security and privacy than Tor?

---

I don't think this is very productive, if at all and should be shifted to a separate thread if you'd like as any further discussions could be a little off topic. From the discussion, I've inferred these points:
1. Tainting whatever coins or UTXO you have doesn't matter. It shouldn't matter because you're using CoinJoin and it doesn't automatically make you culpable of any illicit activities that the funds are responsible for. Not a reason to avoid CoinJoin.
2. The research on breaking Tor's privacy is outdated and infeasible. The nature of Bitcoin onion nodes keeps it within the onion network, eliminating rogue exit nodes. Having Bitcoin onion nodes is NOT bad, it helps people to circumvent regional restrictions and to maintain their privacy. Tor does not make Sybil attack much easier or cheaper. The nature of Tor doesn't result in the privacy to be broken easily. It is the way to go if you have to preserve privacy.
3. Decentralized VPN is a rebranded Tor. It does not mean that it is better, just a less tried and tested way to essentially achieve the same thing.

CoinJoin transactions can inevitably taint whichever transaction that you are making due to it's nature as something that obfuscate the destination address from the outsiders but not necessarily resulting in a complete breakage of links. It is fairly obvious when transactions are actually CoinJoin transactions since they are usually of a huge size as well as having multiple outputs of the same size. Sending to an exchange using a CoinJoin could be a bad idea, they tend to lock accounts that do that for frivolous reasons obviously.

ChipMixers or other mixers in general has distinct behaviors but not necessarily enough for outsiders to pinpoint if they're from a mixer or not.

tl;dr: Exchange can and will freeze your accounts for the dumbest reasons. CoinJoin transactions are easy to identify, transactions from mixers are not so distinguishable.

No. The problem doesn't exist because we do not use exit nodes if you're using nodes with onion address. In the scenario that Wasabi wallet's Tor address fails, it's fallback server has enforced HSTS which prevents SSL stripping. Sybil attack are expensive to execute, at least for Bitcoin Core. You cannot continue the chain without sufficient valid POW and it would definitely be more profitable to just mine legitimately if you have that ability to mine a block.

Traffic has to go through an outpoint for that, unlike Tor which keeps the connection within the network.

DNS Seeds doesn't matter. You're connecting to, not from. Yes, clients prefer 8333 over nonstandard ones.

If you are using a mixer or using Bitcoin in general, most of your coins or addresses are already tainted, with the varying degree depending on the definition of "taint". If you're having issues trying to use tainted coins, then you're going in the direction of "Bitcoin is NOT fungible". If that's what you're thinking then it would be better for you to try to get some newly mined coins and avoid using any other Bitcoins. It is by no means a reason for people to stop using CoinJoin but it is a reason for people to stop using services that defines tainted coins.

The paper is quite outdated, 2014 and there are thousands of reachable onion Bitcoin nodes which ensures that the traffic are unaffected by any rogue exit nodes whatsoever. The paper basically described a Sybil attack over Tor, or at least that was what I understood from skimming through the paper. I assure you that Tor gives you as much privacy as you can expect. Your ISP or your VPN provider has a higher chance of doing whatever is described in the paper.

Wasabi wallet, when used without a Bitcoin Core instance still provides more than sufficient privacy, using BIP158 and to reduce the signature by selecting multiple Tor nodes to fetch relevant information. It also uses Onion nodes only, and taking the exit nodes out of the question.

Yes. But it doesn't change the fact that running a Bitcoin node without the default port will still help the network to be decentralized. The gossip protocol makes it such that port 8333 is not mandatory and it'll still be easy for people to connect to your node via some random port.

Nope. It's not a protocol implementation. I think you can probably integrate it on top of Bitcoin Core though.

It works by having multiple parties spending their UTXOs in the same transaction to multiple output. It requires a coordinator (someone to collate/distribute all the parties and their information) for this to work. An example transaction would be as follows. A spending to B and C spending to D, E spending to F.

TXID:...
UTXO(0.1BTC, A)                           Output (B 0.1BTC)
                                  ->
UTXO(0.11BTC, C)                         Output (D 0.1BTC).

UTXO (0.22BTC, E)                        Output (F 0.1BTC)

                                                   Change(C, 0.01BTC)
                                                  
                                                   Change (E, 0.12BTC)

Since B, D and F are the intended destination, there is no way to tell that A is spending to B and so on so forth.

Yes. There is no way for you to consolidate all the small UTXOs unless you spend all of them in a single transaction. If you want to have some form of privacy, you can possibly try to segregate them from each other and only spending the UTXOs that are associated with the same addresses/ a small group of addresses only.
That is inevitable. Consolidation transactions are best done when the fees are relatively low so that it can be confirmed sooner. If the fees are consistently high, then it'd be better for you to spend specific UTXOs for the transactions that you're making.

The only way for you to preserve your privacy, when spendlinking is inevitable is to consolidate and send them to a mixer or use CoinJoin. If not, then it'd be better for you to use each of the inputs individually.

They do. It's a P2SH address and it should be the one address type that should be compatible given that it was introduced so long ago. Bech32 is also supported on Binance.