Most full nodes actually gets the data from other full node. Lightweight wallet can verify the validity of a transaction but that relies on the full node which it is connected to to be honest.

Assuming that your lightweight client uses bloom filter, it has been disabled in the recent releases by default. I find that the benefits gets marginally lesser and other MITM attack methods are far more viable and less expensive. 9000 nodes is far from little, doesn't hurt to get more either.

No. The communication through USB won't allow for any malware to be able to obtain your secrets. The exploit works solely on the premise that the attacker is able to crack open your device and take the chip out to glitch it.

The main risk with malware is them tricking you into entering a different address and stealing your funds. It is mitigated by checking the screen on your Trezor to see if the address is correct.
That is all to restore all your funds.

There are two types of passphrase. An encryption for the seed or an extension for the seed. The former is recommended for Trezor as there is an unfixable vulnerability which allows for an extraction of the seed given physical access to the device. An encryption on top of it would make the attack practically useless.

The latter is entirely up to you. The seed extension is not covered by the checksum and you might have difficulty when restoring the seeds. Shouldn't be a problem if you were to make a backup safely.

It doesn't. It basically just gives you a very vague privacy analysis which isn't that useful and is completely independent of the time that it'll take for your transaction to get a confirmation.

You've paid a fairly high fee but unfortunately, there are more transactions which pays a higher fee than you. Refer to this site: https://jochen-hoenicke.de/queue/#BTC,24h,weight. When the total size of transactions above 120sats/vbyte is below 1vMB, you'll have a chance at getting a confirmation.

Neither have I. I did a little research of my own and found out that it was introduced in 0.12.0 and the limit is actually 25[1].

[1] https://github.com/bitcoin/bitcoin/blob/4a540683ec40393d6369da1a9e02e45614db936d/test/functional/mempool_packages.py#L18

You don't have to make any new transactions. You'll just have to push all your transactions (rebroadcast) them again.

If you want them to be confirmed, do that first and then spend a transaction with a huge fee, you'll have to do your own calculation; I don't think Core has a CPFP estimation for you.

What wallet are you using?

Older wallets do not recognize bech32 (bc1) format and if you want to use Segwit, you'll have to use nested segwit which starts with 3.

What is the first child transaction? Is that in the mempool?

The thing is, with 1 sat/vbyte transactions, they're most likely already evicted from the mempool and thus any transactions that you've made that is in the range of 1-4sat/vbyte is most likely not in the mempool. Check your transactions, for you to create a child transaction, the parent transaction must be at least be in the mempool. While they may be in blockexplorers, they most likely won't be in the mempool of the nodes that you're connected to and that is why your transaction appears to be invalid. I don't think Bitcoin Core considers orphan transactions.

The "realistic" solution is to find the first child transaction and use abandontransaction on that. Your long chain of transactions probably won't be confirmed and any transactions that you're making won't be valid due to the fact that the ~23 transactions are probably not in the mempool of the other nodes. If you don't want to do so, then yes if the mempool goes below 300MB, you can rebroadcast your whole chain of transactions provided that they're not invalid. Note that even if the mempool gets below 300MB, or ~100MB worth of transaction data, it would still mean that there are still a mountain of transactions before you.

Since OP also requires unconfirmed transaction, I reckon it would be possible to just do a getrawmempool to the Bitcoin Core and arrange the transactions accordingly. Unfortunately, I don't think they are ordered by the time received nor do I know of any API which does that.

Getting the confirmed transaction is probably easier by querying the latest block.

No. However, this is possible if you're using an unhardened derivation path and the master public key is also leaked. It would result in the master private key being derived from a combination of master public key as well as a child private key.

You won't know the 12 word seed even if you get the master private key but I imagine you won't really have any reason for that either.

It shouldn't. The port (9050) that Tor uses is a local port for Bitcoin Core to be binded to. It doesn't make sense to portforward it unless you're expecting any data to be transferred through the clearnet. Having both of those ports blocked should still be fine, that is actually my current configuration with none of those being portforwarded.

It's Tor. It doesn't have anything to do with your local firewall and portforwarding should not be needed, you're binding your listening service to Tor. It would be necessary for clearnet, which is not what OP is trying to achieve here.

OP, try manually setting up the service and see if it works: https://github.com/bitcoin/bitcoin/blob/master/doc/tor.md#3-manually-create-a-bitcoin-core-onion-service.

Only via Grin and on-chain transactions for now.

I don't think Bitcoin.com uses any nonstandard derivation path and OP stated that it's BIP44. The built in function should serve OP just fine and won't be leaking that much privacy nor add any extra complexity.

Is there a specific reason why you need to get the address of the first index?

If you've already called getnewaddress, try using listaddressgroupings.

I think you meant passphrase?

How did you use dumpwallet *DIRECTORY* in that format? It will not output any text in the cli pertaining to the dump but will create a file in the defined directory. The following syntax works for me.

Restore again and this time, click detect existing accounts.

No. Your wallet is not old, it is just a P2PKH format and Segwit is a more efficient transaction format. You don't have to "upgrade" your wallet if you don't want to. People upgrade to Segwit to save in their fees but that doesn't mean it is mandatory. If you want to create a segwit wallet, generate a new seed with Electrum and send the funds there.

No. Electrum doesn't store the seeds for BIP39.

If the checksum passes, then it is probably a BIP39 seed. BIP44 is the standard for the derivation path, BIP39 defines the mnemonic standards. If you click next, you should be able to choose the derivation path. You can let Electrum decide the derivation path automatically and it should work.

Most of Satoshi's block rewards are vulnerable; Bitcoin Core was configured for P2PK in the Coinbase transaction and that makes up for approximately a million (IIRC) of his coin or at least those that weren't moved or presumed lost/burned. Considering that each address has 50 coins, and at current prices, that would be north of 3 million per address. That is assuming Bitcoin doesn't grow further than 60K, which is hard to tell. The economic impact of losing that many coins won't bode well.

You can generate a seed with a checksum that is only valid by Electrum's standards while invalid for BIP39 and follow the version bytes for that. Something like this could be done with a firmware update, depending on the kind of hardware wallets and make it possible to generate/restore Electrum type of seeds.