Same. Big channels are better imho.

You sir get it.

There were just too many software applications that were designed for raspberry pi 4 (NAS, media servers, btc nodes, console gamimg, etc) That's why the buy pressure remained so high, and thus they did not have any incentive to upgrade to a newer version. They did make a great contribution to SBC culture. However, those excessively high prices for 4 full years will be their doom.

The pressure to copy a raspberry pi 4 was too high and so now stronger/faster products are being produced by their competitors at a cheaper price, both copycats and original legit stuff. I don't see raspberry pi being the king of SBD again, ever.

I have tried a lot of chats with the free version of ChatGPT and for some stuff it does know many facts, but in some cases it does not get it right for example about very elemental problems of physics that should be solved with intuition more than math. It does not think, let alone read between lines. However I am just working in something like this, so I'll give it a try.

They just answered in twitter, that they do not have a date yet, but that they will soon replace it for the new version. I hope they do, because I would like to help a bit in the repo since I use Android and I want to get better at Kotlin.

For me the ideal lightning wallet is your own independent node. However as a mobile-only solution I would go with Phoenix. Lightning bitcoin basically is software that runs on top of bitcoin, which are called lightning implementations. There are many (CLN, LND, Eclair, Spiral, etc). The non-custodial 100% mobile wallets that I know are Blixt, Breez and Phoenix. The first 2 run LND while Phoenix runs Eclair. Now considering that we want bitcoin as stable and decentralized as possible, but also we want Lightning to innovate, I believe the less concentration of an implementation the better. That is why I prefer Phoenix since it does not rely on LND. Also, I have read Acinq (the developers of Eclair) have developed a mobile-dedicated lightning client on Kotlin (Eclair was written in Scala, designed for large routing nodes), and they used the Kotlin Multiplatform tech to produce both the Ios and android Apps (the android version is still not released in this version). That is what I call innovation. So far I have not heard of another mobile-dedicated lightning client. But all this criteria is very philosophical, and not so much UX-ish.

Using pure gold is not practical, and using a degraded coin or gold alloy will fail eventually, because you need to trust the minters (government) to keep the gold % constant in the coins, and history shows that authorities have always failed on that task.

Exactly. "Trust me bro, this token is 100% backed by gold, no fake"

Fiat are shitcoins, and the argentine peso is no exception. I hope it does not occur, but I fear a massive bank run (to swap ARS to USD and withdraw), and also a bank shut down (like the corralito).

Well, wallets (regular ones, with notes and coins) often look similar to each other. But real wealth is usually stored on assets or accounts. Hw actually should not perform the wallet function, so they should not even be called wallets. But at the same time they should be easy to move. It's complicated IMHO.

On a second thought, this criteria is not good. Technically it should be possible to send a tx with any amount of outputs. And if people started feeling generous and started giving bitcoin to every existing wallet, the UTXO set will explode but that would be part of the protocol. Maybe another technical solution can be implemented to ease RAM requirements because of the UTXO set. Maybe in the future SSD storage will be fast enough to store everything. Only 87 M UTXOs now. Nodes should be able to handle 9 B UTXOs if btc was to be truly global.

If the ordinals/stamps will increase the size of the UTXO set too much, then I would prefer to soft fork my node and keep out (AKA invalid) all txs that will have say more than x outputs.

I mean, today you need at least 3-4GB of ram to run a bitcoin node. If that requirement goes up to say 8-10 GB because of this, that will make running a node very expensive, and that will hurt decentralization. All I care is to keep running a bitcoin node as affordable as possible. IMHO.

Oh I did not know that. I remember listening to tadje dryja talking about that in 2019 on youtube but I guess he skipped that part for the sake of simplicity. Do you know a good resource for learning about signature aggregation and proposals?

Great! I thought taproot itself allowed that. Anyway the bottleneck here are not the BIPs but the development of software that can make use of those upgrades.

Very interesting description of a bank crisis that started in ireland in the 70s due to bank strikes. Talks about the fragility of non settlement instruments (checks, IOUs), the fragility of trust, but also makes a case for the resourcefulness of people when in hard times.