I don't really think it makes sense for this to happen. The premise of SPV mining and the security of which would assumed to be similar. It doesn't make sense for anyone to do so, simply because it is so expensive and serve little to no purpose other than a few minutes of wasted work, which is far less than the money you spent because most people don't generate a block every 10 minutes. You cannot possibly manage to trick and mislead the pool or miner for long enough, and if you do then the costs of which is far too much (>$190K per block). It is the same principle as an attack on an SPV client, unless your opponent is a small time miner that takes virtually no precautions, then the chances of success is not high at all. Any reasonable miner would be as well connected as possible with multiple redundancies.

Just to reiterate, I don't think anyone is purely SPV mining without any validation but this attack would be as pointless as a 51% attack on the network.

It doesn't affect full nodes which are upgraded.

It is invalid by the newer version of nodes but valid by those older version/SPV nodes. https://bitcoin.org/en/alert/2015-07-04-spv-mining

The timestamp difference is likely not 3 minutes, though that would be indicative of some sort of block withholding/selfish mining but I highly doubt so. It is far more likely for an inaccuracy between the timestamp. From my past experience, my node always received the blocks within ~1-5 seconds of each other which is congruent with the propagation time of the network. You can still use the timestamp as a variable if for some reason you need it though.

The main problem with SPV mining (or mine now, validate at the same time) was the major fork back in 2015 by the various larger pools which has largely resulted in a huge income loss by the larger pools. If you read back on the issue and the topic at that time, they actually didn't really care if they validated the block or not which resulted in a total mess that the community had to deal with. The point at that time was that they wanted to gain an edge over the others, not because of bandwidth constraints. It simply made more sense to just get a server that does it for you or to just join a pool. The profits from the block transaction fee far outweighs the cost.

I highly doubt that any farms would bother to not include transactions because those up/down speed would be okay for stratum, considering the fact that you can still cut down on unnecessary transmissions to the pool. It is still faster and more cost efficient to rely on an external server to compile and feed the data instead of pure SPV mining. With that in mind, most of the larger miners/pools used to use Bitcoin Relay Network or now known as FIBRE but I'm not sure if its still in use or replaced again. They actually do have an edge over the others by that alone though SPV mining was a prominent practice at that time. I think there was some proof that it actually didn't really made sense now with all the optimizations.

Also, at some point in time, the empty blocks might've been due to covert ASICBoost but it isn't happening now that overt ASICBoost is so prominent.

P.S. I don't think intentional sabotage is likely because that is quite expensive in the first place, only happened once accidentally.

Likely node that do not accept incoming connections. They do not show up on bitnodes because bitnodes cannot connect to them through the crawlers. Can also be due to the other reasons I outlined in the other thread as well.
You are only connecting to onion addresses through the proxy because you specified oniononly. However, the reason why you're seeing IPV4 nodes is because you didn't bind your node to your Tor instance. As such, peers are still able to connect to you because you are still listening on your local IPV4 address. To prevent this, add bind=127.0.0.1.

Connections do not necessarily have to be maintained after connections. The primary and intended purpose of your seeds is to establish an initial point of contact to the network and your peers will populate and allow you to connect and get to know other peers.

The list of IPs in the bitnodes site is not exhaustive. Bitnodes cannot crawl and index all of the nodes that are running Bitcoin clients because there are so many and certain nodes might explicitly block their crawlers or just not accept incoming connections. As such, it is perfectly normal to see nodes that were not indexed on the site.

Addrlocal contains your IP and the port as seen by your peer. It can be any arbitrary values because it isn't strictly enforced and certain nodes have it set at 127.0.0.1. If you're interested, the IP address is communicated with the version message in the addr_recv.

There is no incompatibility within any of the addresses. Any incompatibility would've resulted in a failed transaction and in no circumstances would Electrum initiate a transfer to any other addresses for you. It is natural that you can see the funds with a watch-only wallet because the funds aren't moved from that address but you won't be able to spend it without the key.

The only two plausible reasons would be either you forgot about a transaction that you've made or if your wallet is compromised, with the latter being far more likely.

Sounds like either a compromised software installation or computer.

Have you downloaded anything suspicious recently? How did you download your Electrum? Did you verify and check its authenticity?

No way of knowing which miners mined which blocks. The only reason you know certain pools are mining blocks is because they explicitly state it in their coinbase. Otherwise, you actually cannot tell them apart and any analysis can be defeated relatively easily (randomized nonce, timestamps, coinbase, etc).

Also defeating (not weaken) SHA256 or any cryptography like that is quite valuable, certainly not valuable enough to use on Bitcoin.

IIRC SHA1 was considered insecure 2 decades ago or thereabout. The attacks were only somewhat practical fairly recently and even so they incurred quite a high cost and time.

Trezor's Shamir Secret Sharing uses SLIP39 and from what I recall, they are not interchangable. I'm assuming that you're talking about BIP39 seeds. If that is the case, then it is not possible. BIP39 uses PBKDF2 to generate the seed which is a non-reversible function and as such you cannot generate a seed from that. SLIP39 and BIP39 are fundamentally different so they are not compatible in the first place.

BTCrecover actually supports SLIP39. Refer to the documentation here: https://btcrecover.readthedocs.io/en/latest/Usage_Examples/basic_password_recoveries/#slip39-passphrases.

You can see the amount of Bitcoins in circulation simply by looking at the unique transaction volume over the past few weeks/months. That would still be inaccurate because you can always mix Bitcoin and the numbers would be inflated. Both trading volumes and declared holdings by exchange would be inaccurate as well because of the abovementioned reasons. You can possibly collate the number of Bitcoins by looking at the different cold storage and hot wallets of the exchange but it is impossible to ascertain the correct amount because no exchange would give any exact values and you can't possibly find all of the addresses associated with the exchanges, barring larger ones.

It is a simple case of economics. Bitcoin is popular and has its value because of its reputation as the original and the first cryptocurrency.

Literally anyone can create Bitcoin V2, within 30 minutes simply by forking the client and making some minute changes but that is not how economics works. You don't gain the clout and the following of Bitcoin just because you use the same name or have similar parameters on different networks. You'd be a fool to think that Bitcoin's success is only attributed to the different parameters or having Bitcoin in its name.

Nope, probably won't be detectable.

It won't be. The validation on each node is a O(N) problem where you'll just double the work on each node because you have each node validating two hashes on one. The validation effort of the entire network is a O(N^2) problem (CMIIW) because each of the nodes must now do two validations instead of one. There are tons of constraints involved with any changes made to the network and any radical changes have to consider the needs of the network and the possible resource requirements in the long term.

In this case, there isn't any tangible benefits because as mentioned, there is no such thing as a catastrophic failure in cryptography (or at least it isn't common at all in the realm of cryptography). It simply doesn't make sense for us to have to consider something like this when we have far more pressing issues to address first.

I fail to see how this sort of redundancy would be beneficial if at all. If somehow you can generate any valid SHA256 hash at will (highly impossible), then the attacker would be able to dominate and reduce the work done for each block in the SHA256 part. If there is a collision in any of the hash for any set of data, how does the client handle it? Does the client consider both as valid? If it uses the other hash as a check, then isn't it better to just shift to a new algorithm when the need arise?

IMO implementing additional strain on the current resource constraint that we have is unnecessary and wouldn't provide any benefits over the cost.

Transaction 3 -> Transaction 1 -> Transaction 2.

For transaction 1 to have a confirmation, transaction 3 has to confirm first. Afterwhich, for transaction 2 to confirm, transaction 1 has to have a confirmation first.

What kind of transaction are these for; for a payment, a transfer to someone, a transfer to yourself? You can choose to create yet another transaction(which is mentioned above) or to have a replace-by-fee on transaction 3 which will invalidate transaction 1 and 2. Afterwhich, you can choose to create a new transaction that is similar to transaction 3 and continue with transaction 1 and 2.

Replace-by-fee is cheaper than CPFP.

An input that you used is unconfirmed. Check the transaction details and you'll realize that if you check the inputs of the transactions with unconfirmed parent, at least one of the input is unconfirmed.

The amount doesn't matter. Take the total fees of all of the transactions and divide by their size. For example:

If TX 1 is paying 1000 satoshis in fees, 300 bytes, TX 2 2000 satoshis in fees, 400 bytes, TX 3 4000 satoshis in fees, 400 bytes. Then the effective TX fees across all of the transactions would be 7000/1100: 6.3 satoshis/byte. If the result of your calculation isn't at least 12 satoshis/byte then you probably won't get a confirmation so soon.

Transactions can only be confirmed when their parent transaction is confirmed. Certain miners would mine both the child and the parent transaction if the fees are high enough.

You would probably need a much more fees for a fast confirmations and without the details of the transaction it would be hard to estimate how much is required. Do you mind sharing the transaction IDs?

Is it still that random if you came across keys which someone has already swept? It definitely doesn't sound very random to me.

The key space is 2^256. Do the calculations for someone running 1 million instances of 1 million tries per second. How long would it take for someone to find a key assuming that there are 2 billion keys currently. There is tons of math being done on this, so it might be better to just google it first. We would've done something about it if it is really a security risk.

Rate: 1,000,000 * 1,000,000
Key space: 2^256
Number of keys: 2,000,000,000

Ps. That is still many many times of earth's existence.

The crux idea is about pre-image resistance of SHA256 but a bigger issue would be a collision resistance, which is weaker than the pre-image.

Any breaks in a pre-image resistance is incremental and slow over time it is simply too difficult and unrealistic to expect the entire algorithm to be broken overnight. In addition, because we require the inputs to be a specific format and also ensures that it is valid at the current state, it wouldn't be a stretch to think that the pre-image wouldn't necessarily result in a valid Bitcoin block.

Having alternate PoW schemes would provide no additional tangible security benefits while making it more complicated.

That is just fear mongering. Dictionary attacks and bruteforce attacks of that sorts are meant to target non-random and weak keys. They are neither effective, in terms of time and space as well as the cost to yield anything. Anyone can run brute force attacks to generate millions and millions of keys but with the key space so big, it would be impossible for them to find anything at all.

There is nothing to protect at all because no one in the world can feasibly bruteforce any keys generated correctly. If they could, then we would've done something about it by now.