Most bricks would likely happen when the bootloader is upgrading. It probably wouldn't matter what the firmware runs on, if you lose the method of communicating with the host device, then your HW wallet is bricked. I think that the devs are unlikely to really mess it up because there is a certain procedure to test the updates against their device before pushing it out. Failing to test it would just be general incompetence.
Largely depends on if you store everything in your hardware wallet. It might be wise to have a spare hardware wallet so you can seamlessly shift to your new hardware wallet when it breaks without any delay.

The official releases are meant to be stable and they are meant for people to use.

You can clone and compile from the master branch but they are work in progress so they are supposed to be used for testing and not for normal users. If not then, you can compile from the stable branch as well (ie. git checkout [version]). You can validate against the signature when you're compiling.

Simply because you won't be able to generate hashes like these just like that. There has never ever been any attacks which allows users to find pre-image in this manner.

You can do that, but the community won't recognize your chain as valid. It is quite obvious which chain to follow.

As I've mentioned, the manner which the topic postulates SHA-256 to be broken seems to suggest a catastrophic failure of it and for which I'm inclined to believe that the only scenario that happens is when all the other algorithms are also broken. Speed ups in the PoW is counter-acted by difficulty increase, at best there would be a minor reduction in the complexity of pre-image but not financially sensible enough to exploit it.

I think there is a clear distinction between what should be classified as a point of failure, which in this case is how the algorithm can become insecure. I don't doubt that SHA-256 would eventually be broken, but what I do doubt is that it would be broken in this manner. The most likely scenario is that we would recognize its weakness decades in advance and when it finally becomes (remotely) feasible, then we would've long shifted from using SHA256 as the PoW algorithm.

I think that it is fairly unlikely for hardware wallets to actually be bricked because most of them actually validate the firmware for any inconsistencies before applying it. Unsolvable bricks are far few and between.
That might actually be counter-intuitive. Most hardware wallets are actually designed with proprietary firmware and bootloaders to try to minimize additional attack vectors and possible external problems. Running your hardware wallet inside a Linux Sandbox wouldn't help because you now have to consider the security of Linux as well.

No one would realistically send their hardware wallets or anything to Ledger or the hardware wallet manufacturer. I don't find a point in them giving out warranty if you realize that it is virtually impossible to check if the data is cleanly wiped from your device before sending it to them.

Are the addresses that you're trying to sweep empty or do they still have funds?

Do the private keys that you've extracted start with 5, K or L? What errors did you get when you swept it with Electrum?

Blockexplorers are not nodes and they usually have weird criteria when relaying TXes as some of them are custom implementations, which may not conform to the rest of the network. One of the blockexplorers that I've tried before actually didn't allow me to push a SegWit non-dust transaction though the reference limit was lower than the 546 threshold. A more accurate representation would be to directly broadcast to the nodes on the network.

Most of the applications of cryptography in real life requires the property of it having to have a certain degree of pre-image resistance. If that were to be broken, the hash is no longer a one way function, to which it becomes useless for certain real-life applications. Even before that, we have the collision resistance being broken, which already means that the hash function wouldn't be very useful for sensitive operations.
The latter is not possible. As for the former, if you were to approach NSA or related organizations directly, you would probably have a guaranteed payout rather than to attack the chain and risk being labelled a criminal and getting yourself investigated. You'd probably have much better things to do if you could discover a feasible way to generate collisions anyways (at low costs of course).

Anyways, current resistance is still sufficiently high and that is expected for the near future.
Because historically well studied algorithms has never been broken with very little computational power/efforts. If you were to prove that one-way function don't exist, ie. P=NP, then any other cryptography functions would also be dead.
Proving P=NP would be sufficient to prove SHA256 is not a one-way function.

Nope. That is just not what ASICs do.

Then a concrete proof would be good, either that of a past algorithm that has been broken or any theoretical attacks.
You can't really do much once you prove P=NP.

Actually NotATether brought up quite an interesting point that I actually didn't consider.

Any reduction in the complexity of SHA256 either requires a very specific set of hardware or just your regular GPU clusters which allows you to parallelize your calculations. ASICs are unfortunately too specific for this. Pre-image attacks are actually not very common still, I know MD2 was cracked but that required an enormous amount of memory and huge computational resources. You must realize that the complexity reduction of those are not significant enough, MD2 being 2^73[1] with varying memory requirements. In fact, SHA hasn't even been cracked yet, to any extent within the realm of feasibility.

There is no such thing as producing a valid block hash with little computations, that is not within our reach for the near future. If that happens, you can be sure that cryptography is dead.


[1] https://eprint.iacr.org/2008/089.pdf

They do: https://bitnodes.io/nodes/?q=Tor%20network. People running Tor node might not want incoming connections so that might have a lower percentage on Bitnodes as compared to the clearnet. However, those that allows incoming connections are still indexed.

There's no difference between this and newer/more ASICs coming online. You can argue that someone might start mining all of the blocks but even that is unlikely because any breakthrough takes years to progress and SHA256 wouldn't possibly be broken overnight.

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.