MJ

Does Bitcoin have a long-term security plan? Bitcoin might have a major problem and likely an existential crisis when it comes to long-term security. The built-in subsidization model (block rewards) for miners is logarithmic (halving every ~4 years). This means that, in order to maintain the current level of miner hashrate (and network security), BTC's market value must continue doubling between each halving. But BTC's market value can only double another 4-5 times before exceeding the market cap of gold, and only 6-7 more times before exceeding the global money supply. There will literally be no more opportunity for growth. As the block reward diminishes, miners will become more and more significantly dependent on fees for subsidization of their operational costs in order to maintain profitability. This means that fees must rise exponentially in parallel with the logarithmic decrease in block rewards, and will likely surpass $50/tx within 15-20 years. All of this happening concurrently to the existence of at least one alternative that offers instant transactions with zero fees, better decentralization, better security, better scalability, and better usability and a fixed security model that does not diminish with time (this has not been true during previous halvings). As fees grow exponentially, people will migrate to these alternatives, exacerbating the drop in resource investment into BTC. BTC's security model is variable, dependent on continued exponential growth in market value. Its future is, at best uncertain, and at worst will tumble into irrelevance. Why has it become the norm to dismiss these significant concerns rather than focus on an alternative with * a permanently fixed security model * better decentralization * better transactional security * better latency and throughput * better usability with instant full confirmation and zero fees Why should the global economy continue to choose to use a financial system with 30-60 minute latency, 3-7 tps throughput, exponentially rising fees, and obscene energy consumption when an alternative exists that offers instant confirmation with zero fees and negligible energy consumption? Lightning is a decent attempt at providing a similar experience built on top of Bitcoin, but in doing so, it makes absolutely massive compromises to decentralization, custodialization, security, usability, and complexity, leaving it susceptible to bugs, vulnerabilities, and failures. On top of all of this, moving transactions from Bitcoin's base layer to Lightning actually removes fee subsidization from Bitcoin's base layer, further exacerbating it's long-term security problem. In many ways, Lightning is the antithesis to everything Bitcoin represents. It's time to move on from Bitcoin and focus on more optimal solutions.

Open discussion. I get a lot of shit for mentioning Nano anywhere on nostr, but who here has **actually** looked into Nano? **If you have, what did you not like about it?** I've studied Bitcoin for more than a decade, and Lightning and Nano (and many others) for many years now. Nano is unlike anything else I've seen. It is painfully obvious to me that it's a much more optimal solution than Bitcoin+Lightning, and I have yet to see any valid arguments against it.

Just noticed that hamstr.to seems to support markdown to some extent? Testing a couple notations # header1 ## header 2 *italics* **bold** ***bold italics*** - unordered list 1. ordered list 1 2. ordered list 2 `in-line code` ``` block code ``` --- ^ horizontal rule [links](hamstr.to)

What is a "shitcoin"? How do you define what a "shitcoin" is?

Pretty impressive how quickly all these nostr clients are improving! My favorites so far are Amethyst on Android, hamstr.to and iris.to on desktop, but I keep swapping back and forth between these and others to see the progress. Outstanding. Shout outs to #[0] #[1] #[2] and all the other nostr devs out there!

Why couldn't nostr zaps be an open standard with any `payto:` URI payment target? https://github.com/nostr-protocol/nips/pull/262

You can't scale technologies in layers. 🧵 👇 You *can* build applications and reusability frameworks in layers. And no, the internet does not *scale* in layers either. I'll explain below. There is an absurdly common misconception that technologies like Bitcoin can scale in layers. When responding to criticism of Bitcoin's lack of sufficient throughput (4-7 tps) and extremely high latency for full confirmation (30-60 minutes), proponents will often claim that "second layer" systems like the Lightning Network magically solve this problem. This just simply isn't true. *Lightning is not Bitcoin*, and is not attempting to scale bitcoin itself. It is an entirely separate application that leverages Bitcoin as a *feature* for settlement. Unfortunately, as a separate application, it also has an entire transactional model of its own, completely separate to Bitcoin's. One that is far more complex and prone to bugs, faults, and vulnerabilities, is far less decentralized, and tends to be very custodial. Lightning is indeed relatively scalable, but it makes tremendous sacrifices in complexity, security, and decentralization in order to achieve that scalability. Unless running your own node, you're using LN custodially to some extent, whether a fully custodial wallet or at a minimum custodial channel management. This is completely antithetical to everything Bitcoin represents. Graph theory tells us that the complexity of searching for paths between two vertices in a weighted directional graph means that Lightning simply cannot scale without dependency on the formation of massive centralized liquidity hubs, acting as middle-men collecting more fees from the users. This is essentially a reincarnation of traditional fiat banking/credit/payment applications, only built on top of Bitcoin rather than fiat. Yes, Bitcoin provides a much more sound base layer, but the "transactional" Lightning layer is just as compromised as in current fiat monetary systems. We can do better. We can keep the transactional layer on the base layer itself, with significantly improved decentralization, security, throughput, latency, and usability. I also frequently see Bitcoin supporters pointing to the internet as an example of a system scaling via layers. This is very inaccurate. The internet does not scale in layers. Each layer of the internet protocol suite is an application or reusability framework layer, and is as optimized as theoretically possible for its specific purpose. And all of them fully rely on the underlying layers for all relevant activity. None of them are attempting to scale their underlying layers. The HTTP protocol does not implement its own solution for data transfer. It relies fully on protocols like TCP, UDP, QUIC, etc for data transfer. This is not true about Lightning. As I said before, Lightning is a separate application entirely, using its own protocol for transactions and other operations, circumventing Bitcoin's transactional security entirely and using it only as a feature for settlement. Many Bitcoin advocates have seemingly been convinced that it's impossible for a base layer to provide adequate scalability (throughput and latency) without sacrificing decentralization or security. This problem is often referred to as the "blockchain trilemma". What people tend to misunderstand about this trilemma is that it only applies to parameterizations of a particular system architecture. If you take Bitcoin, and make its blocks bigger, or its block time shorter, you can increase scalability significantly. But in doing so, you're likely making sacrifices to decentralization and security. This much is true. But by completely re-architecting the solution from the ground up, we can and have achieved significant improvement across all areas of concern, including scalability, decentralization, security, and usability.

Be honest: what cryptocurrencies, other than Bitcoin/Lightning are appealing to you? And why?

NIP PR for added support for the RFC-8905 (payto:) URI scheme standard for payment invocations https://github.com/nostr-protocol/nips/pull/262 https://www.rfc-editor.org/rfc/rfc8905.html