The security tradeoff, if implemented correctly wouldn't be worse than signing a message, or sending a transaction on the network. It isn't as much about the exposure of your public key since the security risk is still minimal but its more about the robustness of it.

By organizing transactions in their mempool into different fee buckets and see which transactions or buckets are being mined and use that with a time decay. This allows Core to estimate a confidence rate of fees for recommendation. This gist explains better than I can: https://gist.github.com/morcos/d3637f015bc4e607e1fd10d8351e9f41. The PR mentioned in that was merged in 0.15.0.

IIRC the rationale of not using mempool as an estimate was to provide a more conservative estimate. I think if you want to, it can be improved but with some tradeoff so I'm not sure if its worth it: https://github.com/bitcoin/bitcoin/issues/27995.

Anyhow, there is a trend with the fees, or at least a pattern in the frequency that people are sending transactions. It'll definitely be a fun ML project to take on. 

Also have to caveat that you shouldn't be using any random tool for this since there's no standard for this. In fact, the original implementation by jackjack had flaws which was only corrected in Electrum after release. It was not suitable for production and cryptography goes beyond simply just implementing it. Between using a well established standard like PGP and an implementation by wallets, I'd prefer PGP.

Not saying that Electrum is bad, but it does help that PGP is more widely established and researched on rather than the implementations by single wallets.

That's including swap I suppose. If you're trying to keep your chainstate in your RAM, then that's the expected behavior (flushing) which is quite different from using your ram as a tmpfs or ramdisk. If you're using /dev/shm as a ram disk, then you can only use half of the RAM, and you'll have to consider the different overheads as well. Likely would require over 32GB of ram, which would probably mean that it's going to be a couple of times more than just adding half a terabyte to your server.

Yeah, that's why mission critical configurations have ECC and not for normal consumers. Even a slight corruption in the chainstate would be bad.

Bitcoin Core only stores as much chainstate on the ram as you allow it. Keeping the entire chainstate on the RAM, permanently and not as a cache, would probably cause more problems than it solves.

---

Regardless, the behavior for the chainstate flushing during IBD of a pruned node should be that the flushing occurs everytime that the blocks are removed from disk. Even if RAM is extremely reliable and that the server is never shutdown, Core would still attempt to flush chainstate to disk as the IBD progresses. Hence, it is necessary for the disk to have sufficient space to accomodate the chainstate, no way around that.

Storage is far cheaper than RAM, and note that since your entire chainstate is in RAM, any corruption to the RAM would result in a catastrophic failure and thus another reindex. I doubt it wouldn't try to reserve the space for chainstate on the disk at all times. So it'll be far easier to just get more storage.

No good reason why you should use this over PGP. PGP is specifically designed for secure encryption and decryption while this is just good enough, having PGP makes everything much more streamlined with its web of trust and the different features specific for such systems. PGP has more development and hardening as compared to this which uses ECIES and requires you to maintain a separate set of keys for encryption and decryption.

Only flaw is that no one would use Testnet unless they are already using Bitcoin. Unless you're trying to fool some ridiculously incompetent adversary, this probably wouldn't work and would essentially be a confirmation that you use Bitcoin. Distraction won't work at all, and a decoy wallet that contains a small amount of Bitcoin would probably be a better idea.

CPUs don't really benefit that much from the entire concept of security by obscurity but they are proprietary because of the significant R&D and stuff that is going into the chips. Asking them to open source their chips would be quite unreasonable from a business perspective and probably would never happen.

I've got no doubt that HSMs already have their inhouse red team to try to attack and crack their own chips and it is unlikely for an adversary, say a state sponsored attacker at worst to be able to understand the inner-workings thoroughly enough to break the HSM. My take is that security by obscurity works, and that open sourcing stuff doesn't exactly benefit manufacturers from a business perspective, considering the amount of money on R&D and certifications as well as the potential threats by doing so. We've had plenty of vulnerabilities from open source codes and notably some of the more serious ones were not disclosed and secretly used to develop their own exploits. I have no doubt that this could happen if given the chance.

Quite significant, I would expect. HSMs are very specialized chips and they are required to withstand various attacks from sidechannels, fault injections, tampering etc. Most of them are certified and hardware wallet manufacturers are generally more keen to use those that are available on the market, which is often proprietary and closed source as compared to open source ones, likely due to the track record and stuff.

They are obscure for a reason, which likely allows it to benefit from security from obscurity, which is especially important for devices which are required to be secure. You don't want people trying to probe around to see what makes it tick.

HSM is probably one of the most notable one, but I think MCUs are generally not as guarded though I wouldn't doubt if they aren't willing to release schematics on these. These are deterministic (similar design and components are on every device), but given the obscure nature of it, you wouldn't know if any backdoors are already in the chip if you have zero access to the internals.

Hardware wallets are generally tamperproof which means that it would be difficult to exactly inspect each and every component in the device. Let's say you know exactly which components are on the device, which isn't quite difficult (a quick visual scan will do, xray can be used if you really want to be sure), then I don't see how this still wouldn't require the user trusting the manufacturer.

FWIW, hierarchical deterministic wallets like Bitcoin Core requires a new backup given a password change. Certain activities to the wallet will result in a refresh of the HD seed and thereby requiring a new backup. Mnemonics are designed to make it easier for people to write them down and read them.

Not saying that I agree with him but there are merits to this arguments. It's not a matter of inspecting the entire PCB with your naked eye or reading the codes. There's no way of knowing what exactly each chip is for and the entire design and layout of PCB, because certain components are designed to be a blackbox for security. In fact, it would be difficult to tell if your firmware is indeed flashed to the one that you've uploaded to the device.

I think the issue is less about reinventing the wheel and more about knowing what you're doing and guarding against potential attack vectors. If you thoroughly understand and guard against what's potentially a threat, then I don't see how it would be bad since majority of them are a direct result of human error. Not trusting BIP39 is okay, or using GPG to encrypt every single WIF private key is fine too, but it's just a less efficient way and one that doesn't make much sense given the alternatives that we have.

This is not true. The fee market and the demand curve will always have a point of saturation where additional fees and demands doesn't increase the total revenue. Lightning network is absolutely needed to offload some of it on the second layer while still maintaining on-chain settlement.

The cost is related of the revenue of Bitcoin mining, and thereby if your revenue of the miner drops, then the cost to attain X% of the hashrate decreases proportionally. The simple logical way of thinking is that miners won't mine at a loss and a drop in revenue equates to either a scaledown in operation or a slower growth. Even if your efficiency of ASIC gets ridiculously high, the cost of them would be a key factor in whether Bitcoin gets attacked or not.

In addition, we go through this so-called renewal of ASICs when newer ASICs are released. Miners will not purchase them unless it makes sense, ROI is better than the current ASICs and that all of the scrap and cost overheads are accounted for.

---

Block size increase, increased in demand for blockspace, etc. These are the key factors to consider. If Bitcoin doesn't go mainstream by the time coinbase rewards goes to negligible, then it would be an issue.

Storage is important but so is the usage. You'd have to be sure to use your keys only in sanitized environment, and preferably separate from each other in the case of multisig or it'll negate the benefits. Extending your seed phrase would ensure that the adversary won't directly gain access to your wallet but it doesn't mean that you won't be susceptible to extortion or a $5 wrench attack. A good way to keep backups would be either in a safe or if you know what you're doing, hidden with steganography.

You don't have to use IPV4 at all, and you can just portforward and point Bitcoin Core at the IPV6 address. Tor will also solve the problem with inbound connections without any issues, you just need an additional network layer ontop of the IPV4 that you have.

Most blockchain explorers offer a public API for users to query but that'll mean that you would have to trust their information to be accurate. If that fits your purpose, then you can try to use those: BlockCypher, SoChain for example. Caveat is that since you're not able to run your own node and verify the data, there is no way of knowing if they are accurate.

Yeah, it's fine.
Ethereum works quite differently from Bitcoin. With Bitcoin, the message signing function is solely used for the message signing/verification purpose. It is very different from signing a transaction, you cannot just sign a transaction using the transaction ID. It's just common sense for people to not sign messages with content that they don't fully understand.

Transactions have a signature that ensures that the inputs can be spent and is valid. You should not sign any transactions that you cannot trust; but the way that the signature is generated is quite different. Bitcoin signed message has a very specific syntax, so long as you are using the message signing function (not transaction signing) then it would be fine.

No and yes. Nothing would happen if you sign a transaction ID using the message signing tool**, though there is really no reason why you should be doing so. Using the signed message tool for Bitcoin Core would guarantee an invalid signature if used. The transaction data isn't just the transaction hash and since the message prepends "Bitcoin Signed Message:", it wouldn't be valid for a transaction signature regardless.

I recommend including more details like the purpose and for whom, just to ensure that it can't be reused or otherwise misconstrued.

** I'm not familiar about the implementation of Ethereum's wallet but it is not an issue with Bitcoin wallets to my knowledge because the message signing is distinctively different from transaction signing.

Depends, we've seen loads of stuff happening on the computing clusters of quite a few university as well. Cost is only going to get cheaper, until the point where someone with malicious intentions have access to it. Besides, it would be a matter of time, and that is unless you think Bitcoin won't survive for that long.

Government sponsored attacks are not uncommon, just look at the APTs out there for example, and I wouldn't have a doubt that these gets stolen by a semi-big country to evade sanctions.

This is accurate. However, we aren't talking about these Bitcoin addresses in this scenario. Change address is quite commonly used now but P2PK and address reuse was quite prominent previously.  Counting P2PK keys and address reuse, we are looking at more than a million or two Bitcoins, and they aren't necessarily going to be moved before this happens.

Bitcoin-qt at that time used to mine block rewards to P2PK addresses, but transaction between wallets uses addresses.
Legacy to Bech32 and Bech32m didn't gain traction earlier on because many exchanges either didn't recognize these addresses or were still generating legacy addresses. The general reluctance would probably be gone once they realize it's either getting your coins stolen or transfer to a new address.
FWIW, BHT algorithm lowers the complexity for collision finding, which can be dangerous if and only if it is feasible. Finding pre-image of SHA256 would be tougher and isn't a concern, specifically relating to mining. The speedup from doing so is not high enough, complexity should still be around 2^80, IIRC.