I stopped even clicking site links there when it started pestering me to install their app to read articles. I don't have patience for that sort of nonsense.

Hello

We still have the rest of it. Bitcoin may get captured, but everything won't be.

Is there a source that isn't this screenshot? The article itself? I'd like to share it with a bunch of people.

Listened to it, nice man!

Well I asked people in a few online places how the videos were hosted and never got an answer, and looking at the site there was no link to source anywhere, no about, nothing. I don't know if that's changed.

Yes

I was thinking the same thing about that tube site that was all the rage a few weeks ago. I asked the developers multiple times about it in different venues and no answer. The truth is people are just building centralized websites and replacing RSS with nostr and hoping to cash in on the growth of the network. Which is cool, but they're being dishonest about it, which is not cool.

No it's not obvious, I'm trying to understand exactly what you'd expect. You already linked to that tweet.

I'm beginning to think you don't know what you're talking about. You keep avoiding answering my questions and just say "it can't scale" but that tells me nothing except your preference. If I were new to all this stuff and curious asking you what I'm asking you, your responses would lead me to distrust you. You should know the details of what you're talking about if you intend to talk about it.

You said that already, you said it can't scale so if people tried to use it you'd run into problems. What problems?

What problems?

Today I am going to talk about the Trilemma, how it is asserted and presented and it's actual tangible impact on designing permissionless, censorship resistant distributed consensus systems.

The trilemma is as follows: there is a theoretical limit to the total security, decentralization and scalability you can get in any permissionless consensus system. Think of it like when you're setting up a character in a video game: you have a set number of points to give to each available trait, and the more of one trait you give, the less of another you can give.

In the trilemma, you can "max out" 2 of the 3 traits. If you have maximum security and maximum decentralization, you have no (or very little) scalability, if you max out decentralization and scalability you get very little if any security, and if you max out security and scalability you get very little decentralization.

This is at the crux of the BTC block size debate; the prevailing argument is that increasing the block size increases scalability but reduces decentralization. Nodes can't hold the whole blockchain as easily and so the number of nodes drops, the only nodes that continue to exist are those privileged enough to be able to afford the ever increasing storage requirements. This concept does hold water, although I think that decentralization has a lot of other factors and that the blockchain footprint isn't even the most important one, but that's another discussion.

The trilemma is widely asserted and hands are thrown up and we all decide there's nothing to be done about it. Either it's a steadfast law of the universe, or we aren't smart enough and some day, some other smart guy will come in and solve it but for now, we are stuck with it, "they" are working on it somewhere. What we don't talk about is whether we are even at the limits of the trilemma, assuming it is a steadfast rule, or whether "they" have already worked on it and improved it and whether something exists right now that, if implemented, improves the status quo.

There are 3 sets of limits on how optimal you can get a system before you hit the wall of the trilemma: the theoretical limits of what can be done in reality, the practical limit imposed by external factors that are not subject to the rules of the system, and the limits imposed by the architecture of the system we are building. It is entirely possible, and even very likely, that the architectures of the systems we build to which the trilemma applies aren't optimized such that we max out what we can get before actually hitting the limits imposed by the trilemma.

Here's a thought experiment: suppose you have infinite security and infinite decentralization. You could get 0 scalability in that scenario. The network would be unusable. So, practically speaking, you'd have no security or decentralization because you have a non working system. If you had one less than infinity of each, you'd still have 0 scalability. So what's the limit, the point at which you have 1 transaction or user? These limits are the practical limits, that is, you cannot get infinite decentralization, you can only get, at most, a number of independent nodes equal to the number of people that exist, and if younger that you'd have near 0 scalability; nobody would be able to use it. Likewise, you cannot get infinite security, you can only get security equal to the amount of energy that can be expended to guarantee it, and so on. The true line where you get any scalability at all are somewhere below that. Now do this thought experiment with infinite security and scalability and then infinite decentralization and scalability and you'll understand what the practical limit means fundamentally: there are facts about the state of the world right now that impose limits even if our architecture were perfect and in line with the theoretical limits that we could potentially reach. Part of what this means is that we don't need infinite scalability, we only need to resolve the trilemma up to a point where engaging on the network is near frictionless for the people that want to use it, that our practical limitations may say something about our practical requirements.

(It is important to note that with PoW, we are always at the security frontier imposed by the practical limits, because the energy put into securing the network is always the maximum allowable, assuming the cryptography and technology used to do this are sound. I'd also like to point out the fact that technology available to us is also one of these practical limits, but that gets messy because often times technology exists to push these limits that isn't widely used for one reason or another.)

Currently, in Bitcoin, we keep every single transaction in it's entirety forever. This reduces decentralization or scalability, depending on which limit you place on the block size. This is clearly not optimized; you don't fundamentally need to remember every transaction ever engaged in forever to guarantee the security of the network. You do in Bitcoin because of it's architecture, and pruned node schemes that do things like only keep the UTXO set and block headers reduce the security of the network if there aren't enough full nodes. But fundamentally this is not a requirement. This limit is imposed by the architecture of the system. If you could remove this need entirely and only keep the UTXO set, you'd still have the trilemma (I will explain this later), but you'd significantly increase how much decentralization and scalability you can get for the same security guarantees.

So bigger blocks... This doesn't resolve the problem, the architecturally imposed limit still exists. It exists for Monero as well, even with a dynamic block size, because you still have to keep every transaction that ever happened, even though you can't use them for anything at all unless you engaged in them and they're basically random noise, you still have to keep them to get the security guarantee. I would say it's worthwhile, just as many tradeoffs are worthwhile, because of the additional security features you get from it, but as a matter of fact, it is a stopgap, a practical limit, if we could get the same privacy and security guarantees without archiving the entire obfuscated transaction history we would, the Monero community is basically unanimously in agreement on this point.

So, is there an architecture that pushes us to the practical limit and enables us to get more decentralization and/or scalability with the same security guarantees? It turns out there is! It sacrifices some of Monero's security guarantees, given that privacy is a part of the security model, and it sacrifices programmability entirely, but it enables us to keep only the UTXO set and nothing more while still getting the security guarantees that Bitcoin gives us subject to the practical limits.

Mimblewimble, as specified by Tom Elvis Jedusor, is an interactive protocol that, due to the signature scheme used, makes every block into one big coinjoin transaction, and makes the entire blockchain into one periodically updating block. All spent transactions can be safely removed, known as cut through, and the only thing you have to keep are the UTXOs. There is no sacrifice in security as a result of this architecture as opposed to Bitcoin (there is as opposed to Monero, because there's no way to enforce cut through on every node as a requirement and so a transaction graph can be created, which is why Monero doesn't adopt this scheme). In fact, you get a few more security guarantees, amounts are obfuscated, recipients are obfuscated and because of the interactivity, you cannot send transactions to nonexistent addresses, the only way coins can be lost forever is by losing the private key to them, and it is much more difficult to send coins to a scammer because the party you're interacting with has to send you back the signed transaction to receive the coins.

(It is important to note that this is not the Mimblewimble specification employed today, which is slightly different, I'll get into that in a minute.)

In the original MW scheme, you don't even need a block size at all. The blockchain scales with the number of UTXOs only, you can put as many transactions as you want into a block and the spent outputs get cut through, the blockchain doesn't grow by the block size every block (assuming maximum utilization), but only by the number of new UTXOs, that is, coinbase transactions, and sending one UTXO to two or more people. You could have a 10MB block, and if 90% of the UTXOs created are spending existing ones, the entire chain only grows by 1MB. When multiple UTXOs are swept into one, the size of the chain actually decreases.

So the trilemma is solved! Well, not really, I said I'd get to this later and here it is: the blockchain will continue to grow in perpetuity, forever, it just grows at a much, much slower rate. Specifically, keys get lost, coinbase transactions get created, and so, given infinite time it will grow to infinity, but that growth is sub linear with time, significantly less than Bitcoin. But, optimization is at the practical limit; decentralization is inversely proportional to scalability given the same security guarantees, and it approaches the theoretical limit, the size of any given block, and hence it's scalability, is restricted only by the block time and latency of the network itself. Over vast distances, like between planets, you can hit this theoretical limit, but here on earth the real limit is the practical limit of network bandwidth, that is, it is practically limitless. With a combination of PoW and the original Mimblewimble, you have optimized the trilemma such that, while there is still a theoretical limit, block size is no longer a factor and the practical limits on scalability become bandwidth and verification time.

I said earlier that this version of MW isn't the one widely deployed today. The original MW has a limitation: you can only send and receive transactions. You cannot have any programmability at all. No time locks, no multisig, nothing. It's just money, cash. So there's no way to trustlessly enforce conditions on the movement of money on the network, and that's a significant enough limitation that a compromise is called for. This compromise came in the form of Andrew Poelstra's improved Mimblewimble specification, as implemented in Grin, that added transaction kernels. This meant that a small piece of data from every transaction must be kept forever to get the same security guarantees that Bitcoin provides, but with it you get some pretty amazing things. Blockchain growth is still sub linear with time, but a little faster than without the kernels.

(I will digress a little bit here, forgive me. With MW, you get the usual programmability that bitcoin gives you, but in a way that no outside observer can see that it is even happening. You also get the ability to build a smart contract consensus system that has finality on chain but is entirely private between participants, where the entire network doesn't have to verify every transaction within the system at all, as opposed to existing smart contract systems. You inherit the ability to throw away historical state of these systems and only keep the current state of them. For some reason not a lot of work is going into building these systems, but it makes all the work going into things like Ethereum and rollups and attempts at fully private smart contract systems based on Monero futile. I genuinely don't understand why nobody is working on something like this, it seems like a very impactful endeavor.)

One of the limitations of this improved MW is that you still need a block size. It can be significantly bigger than Bitcoin, and can be dynamic, but in order to ensure that blocks get finalized within the block time you have to impose some limit, and that limit can scale as needed and doesn't impact the growth rate of the blockchain besides the accumulation of transaction kernels. It is not a practical factor in the decentralization vs scaling debate. What this means fundamentally is that, when discussing block size with relation to this trade off, we aren't discussing the trilemma at all, we are discussing architectural limitations of Bitcoin and existing smart contract focused chains. The trilemma is not the limiting factor in this trade off, the architecture of the systems we use is the limiting factor. We can, right now, get the same security guarantees, the same or improved decentralization, and significantly improved scalability, with simply a different architecture. The trilemma is no longer a factor when we talk about scalability, our current choice of architecture is. Other considerations limit our ability to scale, not decentralization due to blockchain size.

I believe the trilemma exists, and is fundamental and unavoidable, but I don't believe that the most prominent systems we have today even come close to hitting it's limits. I believe that it is possible to get programmability and perfect privacy without storing any historical state at all, though no such architecture exists today. I believe that there are worthwhile trade offs and considerations other than the trilemma, such as privacy and programmability, that justify not using existing ideas and techniques that push the limits while not satisfying those considerations, as well as justify compromises to preserve those important traits. I also believe that with better network architecture we can approach the theoretical limit on latency and really begin to hit the limits the trilemma sets for us. But for now, invoking the trilemma as a way to say "can't be done" when we are talking about architectures that impose unnecessary limits on decentralization and scalability that can be overcome with things that exist right now is counterproductive.

Do you happen to know a good service that will work with SIP? I'm considering setting up a "home phone" and ditching my cell phone entirely.

That's not the point. The point is, people want btc for example, but the fee is high, so they wait and save dollars. You can do that with anything. I'm pointing out that your reasoning is flawed.

Monero has a use case, peer to peer digital cash. What's the use case of Bitcoin?

I think this is a bit optimistic for Bitcoin. There is no justification for the on chain fees and they'll only get worse. Something can only be used to store value if it can also be used to transfer value. At some point someone saving up $10k worth of Monero will ask why even swap to Bitcoin in the first place.

Why not? People do that with dollars already.

Do you understand how the model works?

Why dies the graph only go back to 2020?

Why are the lines smoothed when looking into the future? What data is used to justifythae future curve?

I just don't see it man, it looks overfitted.

You expect Bitcoin to become globally used and the block space not to fill up? If bitcoin even approaches use by 10% of people, even if they're all using lightning, just opening and closing channels will cause the mempool to grow drastically. It's basic queueing theory and simple market economics. There are 2 options: either fees one day never go back down or bitcoin doesn't get widely adopted.

If you want to articulate an opinion on something someone wrote you should probably read all of it.

The trilemma, you mean security, scalability and decentralization?

There being trade offs does not mean the current state is optimized. There is a protocol for example that preserves the security guarantees that exist for bitcoin, preserves and even increases decentralization by reducing the size of the blockchain, and increases scalability because it doesn't necessarily require a block size. It is called Mimblewimble. In pure MW, as was originally written, the entire chain is just the UTXO set. But there's a trade off: no programmability. No time locks, no multisig, nothing. The version that was ultimately implemented does have these features at a cost: very small leftover pieces from each transaction, called kernels, must be kept. That's a trade off. But the conflict between scalability, security and decentralization has been optimized, and performance can be orders of magnitude better than currently in bitcoin.

I don't know that it's risk free. There is risk to keeping payment channels open, there's the risk that your node goes offline and the counterparty closes the channel. Even with that risk though I do think LN BTC is worth more than on chain BTC, but only up to a point: the value difference between LN BTC and on chain can only go as high as the fee disparity, and probably not that far due to the risk I mentioned above. And ultimately, channels have to be closed eventually, which can be looked at in 2 ways: that either that added third fee for closing the channel makes BTC on an unclosed channel that much more valuable, or on the other hand that ultimately for finality the LN BTC has to price in that cost and therefore is worth *less* than on chain BTC that has already borne that cost. My write up you referenced talks about how ultimately fees break the store of value use case and collapses the value of BTC, and I think that LN BTC wouldn't fare well in that scenario because ultimately it's only secure because it finalizes on the blockchaim eventually. All in all, any arbitrage opportunity requires those 3 fees to be paid (the two you outlined, moving from exchange to wallet, moving from on chain to a payment channel and the one I mentioned, the impending cost to close it) and so those fees would eat up any arbitrage opportunity. The only real way for there to be one would be if the privacy and speed of LN alone justified the price premium.

As far as the political side of the article, political instability does affect perceived value of fiat currency, this is empirical, I don't foresee the supreme court going the way the article speculates.