Countries do make investments, through their sovereign holdings. My point here is not about Bitcoin as a bad investment, it can be a good investment. However, if you notice for any funds that the government holds, they are accountable for it and generally they do have a certain risk allocation to the percentage of funds that they're willing to risk.

I don't think that any governments should be refraining from Bitcoin as an investment but having such a high asset allocation into a risky investment vehicle (such as that of crypto) is not indicative of good governance.

You have to consider what El Salvador is as a country and what they're doing with Bitcoin. El Salvador is a developing country, rampant with poverty (coincidentally as high as that of the adoption rates as you've mentioned). What Bukele has done is essentially gambled with the country's money, which for a country that is so reliant on development aid, is quite a poorly calculated choice to say the least. The country's reserve is especially important because they are essentially the country's worth.

There is nothing wrong with accepting Bitcoin, and there are bound to be people unhappy with this. However, if you see large-scaled protests for something as insignificant as this, something is wrong. Purchasing Bitcoin while doing nothing to address the country's pertinent issues and just tweets about Bitcoin seems quite counter-productive, don't you think?

It is important to understand what Bitcoin is and what is the point of Bitcoin. At this point in time, El Salvador is treating Bitcoin as nothing more than a quick get-rich scheme by publicizing what they're doing with it at every single opportunity that they get. Obviously, most people aren't buying it and rightfully so. Bitcoin shouldn't be treated as a precious asset for hodling and not for spending.

I think the whole point of mass adoption is obviously not just about the government recognizing Bitcoin as a legal tender and for their own reserves. It is important to encourage businesses to adopt it as an alternative payment and adopt sustainable practices over the long term. It cannot be a distraction from the issues that the country is facing. Adopting Bitcoin while fulfilling an alternative agenda is just a farce in general.

I think those are the floating fee estimation which would be okay if OP is trying to estimate the fees for their transactions. I think OP is trying to get the range of fees, mempool.space also offers an API call for that: https://mempool.space/api/v1/fees/mempool-blocks(https://mempool.space/docs/api/rest#get-mempool-blocks-fees). The extremes of each block denotes the range of fees included in that estimated block.

SPV wallets would probably not be very good for any service in general, simply because they are very sensitive on both the security and the privacy aspect. I would probably recommend you to get a stronger server instead, because if you can't hold the entire blockchain with your storage, then your server has a good chance of not being strong enough.

Using multiple wallets won't be viable for use-case with loads of individual wallets because that would result in a huge delay when synchronizing and loading up the various wallets while offering little to no benefits in terms of segregation. Having a database with the different addresses tagged to each user would be a far better option both in terms of organization and efficiency.

I think given the price to performance as well as the longevity aspect, the energy efficiency of HDD vs SSD would be negligible or simply a dollar or two extra per year, maximum. The price of a HDD is ridiculously low compared to SSD of similar size. The noise produced by HDD is actually quite overstated most of the time and it is barely audible.

Regarding the cooling required for RPi4, I ran into some throttling with RPi4 during synchronization and slapped a heatsink, which more or less solved the issue. Active cooling wasn't really necessary in my case. Never really an issue with the previous revisions though (7w vs 5w). It is still painfully slow regardless.

If storage space is really a concern for you, then wouldn't an SPV wallet be a more suitable alternative for you? Electrum would suffice, without having external API or stuff like that.

The wallet will be synchronized from the point which you've closed it. It shouldn't really be a problem because I think that all of the wallets are being initialized and synchronized at the same time regardless of if you're opening it or not. CMMIW on that, but it obviously wouldn't apply if you're importing a wallet in the future.

Perhaps a P2SH timelock or Multisig would be a more suitable alternative, broadcasting transactions and the handling of the data can be a little bulky. It'll be a bit of hassle to spend the coins at the same time because the signed TX would have to be re-generated every time a transaction is made.

I don't believe that there is a perfect way of doing so. There's multisig (ie. 2-of-3) but you'll always have to trust that the last key would only be revealed after your death. Transaction size of Multisig is probably a non-issue but I would have some doubts that certain parties won't collude to steal the funds, even if they are only stated to be revealed after death in the will.

Reimbursement of lost/stolen funds isn't a point that should incentivise people to use fiat/whatever payment method there is. It is a stupid excuse for people to have and it acts too much like a safety net that people can rely on. That shouldn't be the case, each individual is responsible for their own funds and in no circumstances should anyone be babysitting you or reversing your transactions at will. Coincidentally, payment methods like those also highlights the flaw with certain transactions that deals with intangible items, and resulting in a hard to proof scenario.

The main problem isn't the fees, it is the scalability and the transaction settlement. On-chain transactions cannot scale nor can it be faster than traditional payment methods. You are bound to face certain instances where you find the transaction fees surging after you send the transaction, and you end up waiting a ridiculous amount of time and spending more time trying to RBF it.

I agree, LN is not a solution. It merely alleviates the problem to a certain extent because you would still eventually be bounded by on-chain capacity when it gets large enough.

No good way to really do this because prune works by the size of the blockchain and not an absolute block height. It is not what it is really designed to do anyways.

I'm currently running a pruned wallet on one of my PCs and I've never opened the other wallets for a few months and they seem to be synchronized just fine. I'm inclined to think that they are actually initialized at the start of the synchronize and they synchronize in tandem so it isn't really an issue if you don't open any of the wallets for a long time. I could be wrong, but I know that at least the wallets are checked at start up.

You can parse the mempool yourself if you require such data. The range of fees are not fee estimations but rather the range of fees in each segment. If I remember correctly, and from the looks of it they use the range of transaction fee rates within each segment of the mempool. I don't think they account for the growth rate of the mempool with respect to time so take the accuracy of it with a grain of salt (if you're estimating the fees of course).

Anyways, I'm not aware of any current implementations that does things like this. As mentioned, estimatesmartfee is the way to go. If you cannot work with that, then something that could work would be to dump the mempool (getrawmempool), organize the transactions in descending order. Then segment the transactions according to the size, get the boundaries of each segment and you're done.  This shouldn't be too difficult to do, might have some time to do it in the coming weeks but no guarantees.

Edit: There's mempool.observer as well as jochen-hoenicke.de/queue but they are both visual representation.

It will definitely not be. The key determinant of a successful country is by their economy, which is in turn influenced by different factors, (HDIs, Corruption, Policies, etc etc). If you were to look at El Salvador at its current state, for a supposed democratically elected leader to call themselves a 'dictator' is absolutely ridiculous.

For El Salvador to even escape the labelling of 'developing country' requires so much more than prudent investments (Bitcoin is not one) but also sustainable and rational steps.

It has nothing to do with the fee rates of a transaction.

The fees as stated in the code is actually referring to the dust relay fee instead of the actual transaction fee. This is a user-configurable parameter but the standard is kept at 3sat/byte to maintain the 546sat dust limit that was before the introduction of this dust relay fee. But yes, if the user changes the dust relay fee, then their node would see a different dust limit.

This is not eco-friendly at all, quite the contrary actually. You have tons of inefficiencies arising between the supercharger to your Tesla and from the Tesla to your rig. It only makes sense if the electricity is free and again, that is not an ethical way of doing things. They are meant to charge your Teslas to drive and not to mine and I wouldn't be surprised if there is a clause in their agreement that prohibits this.

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.