Couldn’t add location via https://www.fmon.io 🤷‍♂️ but here is some hints for those who will be here someday 👇 https://video.nostr.build/3c852e5e64d1f939b0e25019aff2cf357f6593b8c08ced3c9a6307414a5f5400.mp4

A bunch of people have been shilling [Liquid](https://liquid.net/) has a scaling solution with on-chain fees on the rise. I wanted to take the time to breakdown why this is a fool's errand and there are better ways to go about this.

Liquid is based on [Elements](https://github.com/ElementsProject/elements) which as they claim in their README is `a collection of feature experiments and extensions to the Bitcoin protocol`. Liquid is just another blockchain. It is a fork of bitcoin with a few fancy things added (Tokens, CT, covenants) and bundled together with a 1 minute block time, federated custody, and some blockstream branding.

Blockchains do _not_ scale. As we are seeing today, the bitcoin blockchain does not have enough throughput for everyone's transactions. This is for good reason, keeping the cost of running a full node low is a priority, this was one of the main reasons the blocksize wars were fought.

So why does Liquid exist? People lately have been touting it as a way to ease fee pressure but in my opinion this is a fool's errand, no different than people back in 2017 saying to use litecoin because fees on bitcoin were too high. Liquid is just a fork of bitcoin, it has the exact same scaling problems and the only reason it has smaller fees is because it is never really been used. For now, it can work as a temporary stop-gap (essentially finding arbitrage for fees), but building actual infrastructure on top of liquid will run into the _exact_ same problems as on-chain bitcoin.

The problem is that Liquid is trying to use [trust as a scaling solution](https://trustisascalingsolution.com/) but did it in a completely inefficient way. When you are trusting the 11-of-15 multisig, you don't need all the benefits that a blockchain gives you, everything is dictated by the functionaries anyways. The problem is if liquid gets any meaningful amount of users it will also end up with huge fees and we'll be back to square one because Liquid's architecture didn't actually leverage any of the trust tradeoffs it took and just inherited all the same problems of on-chain bitcoin.

There are real solutions available. Lightning is the obvious alternative but it does have it's own problems, I think a lot of people have been seeing the problems with small scale self-custodial lightning, it is extremely hard to scale. This is why I am extremely excited about [fedimint](https://fedimint.org/). Fedimint has almost the exact same trust model of Liquid (a federated multisig) but is built on a much better architecture that actually allows for scaling. Fedimints don't have a blockchain but instead operate as a chaumian ecash mint. This allows for them to do actually innovative things instead of just being bitcoin plus a couple features. There isn't a block size, instead the transaction throughput is just gated by the processing power of the guardians. Smart contracts are limited by having to do everything on-chain with bitcoin script, they are pure rust code and allows for all sorts of crazy things. And it all still interoperates with Lightning, essentially giving a Wallet of Satoshi with way less rug-pull risk, tons of new features, and is extremely private.

All this said, it is sad we aren't talking about self-custodial scaling solutions. Today the only real one is Lightning and with current fees, it isn't reasonable unless you have a few million sats. The problem is that this is just inherently a limitation with Lightning. Lightning is excellent when you have high value channels and can make payments across the network, but it does excel at "pleb nodes" where one guy puts 100k sats to try it out, this comes with too many limitations with paying on-chain fees and needing to have reserves to pay future on-chain fees. However, this is potentially solvable. Lightning has solved the problem of scaling payments, where if you have channels, one on-chain transaction can represent many actual payments. What lightning did not solve is that one utxo still represents one user, and this is the limitation we are running into today. Currently the only way we solve this is using a multisig sig (Liquid and Fedimint), but we can solve this in a self-custodial way if we activated covenants. Covenants essentially let us give fine grained control of what is going to be spent from a UTXO before the UTXO even exists. Currently, there are a few proposals (CTV, APO, TXHASH) all with varying ways to do it and different tradeoffs, but imo something like this is desperately needed if we want any chance to scale bitcoin in a self-custodial way.

https://cointelegraph.com/news/el-salvador-bitcoin-freedom-visa-sell-out-end-2023

nostr:npub1qtvl2em0llpnnllffhat8zltugwwz97x79gfmxfz4qk52n6zpk3qq87dze, to filter coinjoins. These present an innovative tool for increasing Bitcoin’s privacy and, when constructed properly, coinjoins can easily stay within the OP_RETURN limit (indeed, there is no reason for them to have *any* OP_RETURN data at all). I have some ideas on how to alleviate the recent issue where some coinjoin transactions were flagged as spam from Knots v25, and I am willing, with the full resources of my team, to work collaboratively on a solution in good faith.

Bitcoin does and always has allowed nodes to set filters based on multiple sets of criteria and Knots v25’s defaults are IMO what is best for Bitcoin at this time. Others may disagree and that is ok. They are free to (and should) run their own nodes - it is good for Bitcoin to have more people running nodes, including miners, and there should be a natural diversity in node policies. As was stated before, OCEAN is on a path to decentralization and very soon we are going to be in a position where hashers will be able to fully participate as miners and perform the intelligent parts of mining such as deciding which version of node software to run and what filters or other policies to apply to block template construction.