kinda like how Bitcoin fractured the money community?

That's correct. However, as Block is already demonstrating with Square/Cashapp, bitcoin payment rails doesn't have to mean that payers and payees necessarily have to ever even know that their fiat payments were transmitted as Bitcoin. What I'm asking for is that the payment rails be via decentralized, permissionless, more cost-efficient Bitcoin - with voluntary usage of services that offer bridges from/to fiat (e.g. cashapp, square, etc) for those who just don't want to hold bitcoin due to volatility (or any other reason), rather than reinfocing the backwards status quo of the other way around. PS. I do think bitcoin volatility will continue to drop, but I personally don't believe it will ever be as stable as the U.S. dollar is now, for example... After all, it's way easier for a centralized authority to manage a slow leak of value in the dollar than it ever will be for a free market to stabilize the exchange rate of Bitcoin.

... and this is in addition to the ~9% drop already since early November.

I don't know if what we're seeing is a short squeeze on precious metals due to a massive unwinding of paper derivatives... but this is what I imagine such a short squeeze would look like.

... and no, personally, I would not feel secure having my life savings in something I don't consider to be self-custody (i.e. including self-recovery).

Fantastic conversation! You're absolutely correct about being pragmatic and meeting people where there at. However, long term, to get people to want to spend bitcoin, we have to move beyond building bridges to fiat payment rails. Bitcoin has already demonstrated that it's a superior money for savings. Bitcoin can also be a superior money for payments - but not while relying on an underlying inferior fiat foundation. Until the payment rails are in place to use Bitcoin as the superior money for payments that it is, we shouldn't be expecting people to want to spend bitcoin.

No, the cloud key IS encrypted with the bitkey device... but as long as you still have the unencrypted version of that key on your phone (in the app), you don't even have to bother with decrypting the cloud key in order to coordinate with bitkey to setup a new device (and new 2-of-3 keyset). The only purpose for the cloud key is in case you lose your phone (or delete the app), you can decrypt the key stored in your cloud (using your bitkey device) for use on a new phone. *there are also encrypted version(s) of your app key stored in YOUR cloud that your recovery contact(s) hold the decryption key for. In case you lose both your phone AND your bitkey device, installing a fresh app on a new phone will allow you to use the decryption key held by a recovery contact to recover your app key from YOUR cloud - which in turn can be used to coordinate with bitkey to setup a new device (and new 2-of-3 keyset). Of course, the app on your phone combined with the app on your recovery contact's phone handle the coordination of all this to make it reasonably painless. (minus the waiting period you mentioned earlier). Again, assuming designed as advertised (which I think is fair to question), I think it's pretty clever. My biggest problem with bitkey is that they advertise it as "self-custody"; but unlike virtually any other hardware wallet, if you lose the bitkey device, because it's designed to have nothing to backup (e.g. a seed phrase), self-recovery is not possible. In my book, reliance on a 3rd-party for recovery necessarily disqualifies it as self-custody.

I think it's worth pointing out that even when you install Signal from Apple's App Store, for example, you are trusting that that binary actually corresponds to the open-source code-base in Signal's repository. That is to say, if you can't independently verify what an app store is giving you, then you are inherently trusting that app store with ANY app it is giving you. But yeah, in addition to WhatsApp not being open-source, it should already be well known not to trust WhatsApp (i.e. Meta) by reputation alone.

PS... Apparently, your recovery contact(s) would also have what's necessary to decrypt your app key stored in the cloud... so, potentially, if FBI compromises Bitkey server, your cloud provider, and also somehow a recovery contact, I suppose your wallet could be at risk without you necessarily ever even knowing it.

https://www.youtube.com/watch?v=z9XyJTUbN6U

Yeah, that's what I was trying to say with "coordinate with Bitkey to transfer funds (via the mobile app key and the Bitkey servers key) to an entirely new 2-of-3 keyset"

Imagine the short squeeze that would occur if a massive amount of paper gold and silver holders demanded delivery from custodians that had been fractionally reserving their stashes. I don't know if that's what we're seeing; but it's an explanation consistent with what we're seeing (including why bitcoin price seems entirely uncorrelated).

Assuming designed as advertised, of the 2-of-3 keys needed, Bitkey servers controls 1 key, the mobile app controls 1 key, and the hardware device itself controls 1 key. There is also an encrypted backup of the mobile app key stored in your cloud account - which requires the hardware device to decrypt it. In short, in addition to the key from Bitkey severs, the FBI would also need either your hardware device, or the key from your mobile app (which I suppose could potentially be lifted through some sort of spyware and/or malicious version of the app). *The key controlled by the hardware device isn't backed up anywhere (it's designed to not even be possiible). If the device is lost (or just stops working for whatever reason), the user's only recourse is to hope to still be able to get a new device and hope to still be able to coordinate with Bitkey to transfer funds (via the mobile app key and the Bitkey servers key) to an entirely new 2-of-3 keyset.

Yeah... I'm sure macOS "just works" even better than Linux. My problem with Apple is I've had an iPhone for a long time; and, I love it. But, I also know that "just works" with regard to Apple products means how Apple thinks it should work... which I wouldn't mind so much if how Apple thinks it should work didn't seem to change with every update (which aren't really optional long term).

This is pretty cool. However, clearly, the merchants must be paying some service to process the receiving of funds via these QR codes. Call me crazy, but in a region that doesn't already have a similarly ubiquitous QR code system, if you're going to try to convince a bunch of merchants there to start using QRs, why not just go straight to lightning QRs and allow them to eliminate the middle-men fees altogether?... In the case a merchant still insisted on being paid in fiat (or just didn't want to go through the trouble of managing their own lightning node), THEN they could choose to pay a middle-man to make that happen... e.g. what Square already offers.

I just tinker with things other than my OS. For clarification, by "too old", I just meant for me - relative to the younger me who would be happy to spend a whole day just to get my desktop color scheme just right I imagine there must plenty of people older than I who still find it enjoyable to tinker with every little minutia of their OS.

In the context of I'm too old to want to tinker anymore, and I haven't owned a Mac since the 90s, Windows drove me to Linux Mint in ~2017. At the time, I did my research and was convinced that Mint was the best "it just works" option (provided your hardware was at least a year or 2 old to ensure driver compatibility had been developed), and I haven't looked back. It wouldn't surpise me if there are even better Linux options these days, but I wouldn't know because I don't even bother keeping up with the latest versions of Mint for years at a time - because it persistetnly "just works" (and did I mention I'm too old to tinker? 😉)

God willing, one day in the not too distant future, even will have to recognize smaller units of Bitcoin such as millisatoshis. I wonder if would just try redine "bitcoins" again? or if he would finally see what an unforced error it is to try to do so in the first place.

oof