I think it should be more of having access your private keys or not. The benefits of having a full node mainly lies within the fact that you're validating the blocks yourself as compared to most SPV wallets which Ledger relies on. SPV wallets functions on trusting the longest chain difficulty-wise to be valid, while this doesn't guarantee that the blocks are exactly valid, it would prove that there is sufficiently high proof-of-work on that chain itself and would be probably valid. This shouldn't actually cause any issues or pose as a security risk in normal use. The privacy aspect would favour full nodes greatly though.

If you have to get a second source for the transaction, you can try querying the transaction ID or the addresses on the blockexplorers as an alternative source.

If you're going in that direction, I'm almost certain that it would've been gone if there was any pattern with the private keys.

Satoshi was mining using the earlier versions of Bitcoin-qt and thus you'd want to inspect the source code of the earlier clients for any possible weakness during the generation which I can say, there isn't any. I highly doubt that the private keys were not generated randomly; he would've wanted to test out the entire generation to ensure that it's working. If it was weak, then one of the many machines running the generators for weaker keys would've cracked it already.

This: https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki#Low_S_values_in_signatures. I think it was replaced by BIP66 for the enforcement of specific DERs signature though.

It was a factor causing the transaction ID to be malleable during that period of time.

AFAIK, the authors doesn't create any clients for altcoins. You can just fork the source code for both the servers and the client and modify it to suit your coin.

The GitHub repo for the Dogecoin doesn't seem to be very active at all. There hasn't been any new releases for over a year now. You'd probably want to focus on that first before tackling the SPV wallet problem.

It should never interact with the internet and thus it shouldn't matter if the user is using VPN or Tor.

Care to elaborate? I find browsers risky given the fact that there could be exploits surrounding the extensions or the plugin which could compromise the security. In that aspect, when generating the funds the main factor should be the randomness of the private keys being generated. From what I can tell, it takes the entropy from multiple sources which should be sufficient to ensure the security of the seeds.

Lower your dbcache. You've set your dbcache to 2000 which would essentially use your entire ram that your RPi has, and I don't think Bitcoin Core will automatically lowers it. The likely case is that some of the UTXOs gets dumped onto the ram fairly quickly and exhausted it. Delete the dbcache configuration or put a more conservative estimate, say 100MB and observe your processes. You can increase it slightly if it doesn't consume all your ram.

You cannot measure the number of wallets that is 'active' because the concept of wallet doesn't exist and there isn't a way to measure it with any certainty. If you were to correlate the number of unique active addresses to the number of active wallets, you'd likely have a skewed results. Most wallet usually introduce an additional address after a transaction and if anything, it could be more of an indication of people moving their funds in the transaction rather than the number of active Bitcoin wallets.

It is completely wrong to say that there are 682,000 new wallets being created but rather there are new 682,000 new addresses that has been used. Those addresses could very well belong to 10 or 100 people and thus wouldn't provide any indication to anything else.

Because it's called BITCOINtalk not BITCOINTALKtalk?

You really don't need to create so many altcoins for nothing.

Transactions do not contain any timestamp, and hence it doesn't matter when you crafted and signed your transaction. However, several years ago, some clients were generated high s signatures which was non-conical and thus those transactions were not standard and unable to be relayed.

Check the transactions for the fees/byte and whether the recipient of the funds is still correct. Even if it's somehow invalid, it wouldn't be stuck at all, it'll just be as if it has never been sent. If you do have a low fee without opt-in RBF enabled, then it could be possible for your funds to be unconfirmed for a period of time. As long as you still have access to the private keys of the paper wallet, you will be fine.

They're sent to an address that is crafted specifically to make sure that the private key to the address would be extremely difficult/near impossible to find. They basically used whichever characters that they like at the start and made sure the checksum checks out at the end. Those coins are indeed burned because they are sent to an address for which it's corresponding private key could never be found, essentially removing it from circulation.

It is still secure to use. There isn't much development because it does what it is supposed to do and nothing else. I would recommend you to just use the github repo link and download from there instead of using/downloading the website offline.

I would prefer to have Segwit paper wallets but it isn't too difficult to convert it from that website after generating the private keys, downside being it won't be a simple process.

Most Electrum servers tends to raise their minimum relay fee for their mempool when the mempool gets too big. If you insist on using 1sat/byte, you'd want to use Export>Copy to Clipboard and go coinb.in/#broadcast or other similar utility to broadcast the raw transaction, they shouldn't have such restrictions.

There's a bunch of sanctions on US goods to countries like Syria and the other countries on the US list and I would assume that Amazon has to abide by that as well, so I don't think they do.

Not sure how the economy works there, there's just too many import restrictions caused by the sanctions and I imagine it could be more expensive to obtain those items.

The mempool doesn't actually get flushed at fixed timing, nor flushed at all. Individual nodes has their own mempool and by extension, their own mempool policy. This means that the time for which the transaction gets dropped by the nodes varies with the parameters or the time for which the transaction gets relayed to that node. (I misread this part and assumed that you were talking about it in a literal sense.) Most accelerators merely rebroadcasts your transaction which does very little for your transaction, other than helping it propagate better. I doubt that anyone has actually had their transaction confirmed as a result of the "transaction accelerators" and without paying a pool to help them.

---

OP, I think that it might be a result of a fairly bad propagation to the block explorers and you won't be able to see them. If you want, you can go to Windows>Console and type in this
Copy the output which is just a long string of characters and paste it here:
https://blockchair.com/broadcast
OR
coinb.in/#Broadcast

When you search up the other transaction ID on blockchair.com, is the field 'Replace-by-fee (RBF) enabled' YES or NO?

The definition of 'tainted coins' is not defined strictly. Depends on how you define 'taint', you can classify those addresses which has received tainted coins to be part of that 'taint' or to consider it based solely on whether that specific UTXO has been associated with the tainted coins. Bitcoin addresses are recommended to be a one use address and unless the criminal wants to waste substantial amount of Bitcoins to taint, and AFAIK most don't consider addresses with dust spam UTXOs as tainted, it wouldn't be of much use.

The concept of tainted coins, tainted address is just a way to make Bitcoin less fungible and I do not agree with that concept at all.

You can manually select the outputs to be used to isolate the outputs from the different addresses.

Yes. If you compare it to having no change address at all, it would be obvious which of the outputs are for the recipient; one of the output will always go back to the same address as the change. Having multiple "addresses" in the transaction is the same as spending the same number of UTXO(unspent transaction output) as a public key as well as the signature has to be defined for each of the UTXO. There is thus no penalty with using, say 3 different addresses and 3 different UTXOs.

You can run your own server with little difficulty. I don't foresee it being a problem; the source code should be archive and you can probably build your own copy and run your own server.
If you want to use the seed to extract your private keys, Electrum doesn't follow BIP39 seed format but it's easy to convert their seed phrase into a BIP32 seed and would give you access to your master keys as well as the derived child keys.

The format should be like this: walletpassphrase "PASSWORD" 600

Replace the PASSWORD with your own.

Just to confirm, is your transaction replaceable? Go to https://blockchair.com/bitcoin and search for your transaction using the transaction ID of the transaction that you've abandoned/removed. At the field labelled "Replace-by-fee (RBF) enabled?", does it say Yes or No?