-
@ e1ff3bfd:341be1af
2024-01-06 19:41:35
Over the last few months it feels the bitcoin community has gotten more and more jaded on lightning. To be honest, this is for good reason, back in 2017 we were promised a decentralized payment network that would always have cheap payments and everyone would be able to run their own node. Nowadays, the average lightning user actually isn't using lightning, they are just using a custodial wallet and the few of that do run lightning nodes often find it a burdensome task. For us at Mutiny Wallet, we are trying to make this better by creating a lightweight self-custodial wallet and in my opinion we have been executing on that dream fairly well. In this post, I'll analyze these issues and present a new way to view lightning and what that means for bitcoin going forward.
First and foremost one of the hardest UX challenges of lightning is channel liquidity. No other payment system has these problems today besides lightning so this often confuses lots of users. To make matters worse, there aren't any practical hacks that we can do to get around this. Muun Wallet used an on-chain wallet + submarine swaps to get around the channel liquidity problem, this worked very well until fees went up and everyone realized it wasn't actually a lightning wallet. The better solution is JIT liquidity like we do in Mutiny or splicing like that is done in Phoenix. These solutions abstract some of it away but not enough, we often get support questions confused on why some payments have fees and others do not. The fact is channel liquidity is not a usable UX for most end users.
The other major pain point of lightning is the offline receive problem. Inherently, you must be online with your private keys to sign and claim a payment. There is technically an ongoing spec proposal to be able to work around this (essentially creating a notification system of when people are online to receive payments), but it doesn't solve the fundamental problem and still has limitations. There has been a few attempts to get around this, most notably was Zeus Pay lightning addresses. These essentially worked by just creating stuck payments and waited for the user to come online to claim, this caused a ton of problems for people and even forced us at Mutiny to block users from paying them because it caused so many force closures. This is a hard problem because the entire rest of the bitcoin/crypto ecosystem works by just copy-paste an address and you can send to it whenever, there isn't caveats around asking your friend to open their wallet. This is further exacerbated by things like lightning address that requires a webserver to even get an invoice in the first place.
Channel liquidity and offline receives in my opinion are the two most obvious reasons why self-custodial lightning is not popular. When most users hear about any of these, they just think screw that and move to a custodial wallet because it is so much easier. If these were our only two problems, I think self-custodial lightning would be fine, it may never be the predominant way people use lightning, but we could get the UX good enough that we have a significant portion of people using lightning in a sovereign way. However, there are more problems under the surface.
Channel liquidity is a problem, but it is also deceptive. When you have 100k sats of inbound liquidity you would think you could receive up to 100k sats, but this isn't the case, often you can't actually receive any. This is because of on-chain fees, when a payment is being made in lightning you are creating pre-signed transactions that have outputs for every in-flight payment, these outputs cost potential on-chain fees and the high on-chain fees go the more it eats into your liquidity. After we've solved most of our force close issues Mutiny this has been number one support request. Even if you do everything right, understand liquidity and have enough for your payment, sometimes it still won't work because on-chain fees are too high. This is always really discouraging because isn't the whole point of lightning to not have to
pay on-chain fees? Fundamentally, all current lightning channels could become entirely useless if on-chain fees went high enough because a single payment would require too many reserves. Obviously this is hyperbolic, but I hope I am getting the point across that on-chain fees don't just effect the opening and closing costs of channels, even if you are a diligent node runner that only opens channels when fees are low, that is not enough, your channels need to be large enough to pay for the on-chain fees of each HTLC at any future on-chain fee rate. As on-chain fees go up and up this problem will only get worse.
The proposed solution to these reserve issues are things like anchor channels, package relay, ephemeral anchors, etc. These are all well and good but kind of just mask the problem. They do solve it so the fee reserve can be much lower and possibly zero, however with the tradeoff that you need on-chain funds available to fee-bump your force closes so they can actually get into a block. This again breaks the UX for self-custodial users because they _have_ hold on-chain funds alongside their lightning funds so they can do those on-chain fee bumps. The size requirements for their on-chain funds is still dynamically based on how high on-chain fees can spike. Solutions for this can include having someone else bump your transaction fees but this brings basically a trusted 3rd party into the mix and isn't ideal.
When you lay out all the different tradeoffs a lightning node needs to make, especially in a high fee environment, it makes me think, what are we doing here, are we going down the wrong path? Lightning is still fundamentally a fantastic payment protocol but its limitation is that it requires _scale_. Basically every problem I've outlined goes away when you have a large lightning node with lots of liquidity and high uptime so many we should optimize for that. The market has been telling us this for years already, +90% of lightning users are using custodial wallets because it works so much better at scale. So how can we use large scale lightning nodes without custodial wallets?
Combining existing large scale lightning infrastructure with self-custodial solutions sadly, isn't totally possible. The only real way to do that as of now is Muun Wallet which as we talked about earlier, doesn't really solve the problem because everything is just an on-chain transaction. However, Muun was onto something. The architecture of having a simpler protocol interface with lightning is genius and gives us the best of both worlds. We can make fast cheap payments and let the big boys collect fees for running the lightning node. Aqua Wallet just launched which is essentially a Muun Wallet but on top of Liquid, this is a good bandaid fix but doesn't get to the root of the problem.
Before we go further we should take a step back and break down what problems we are trying to solve. Bitcoin has a fundamental scaling limitation through the block size, if we could make infinite, then we wouldn't necessarily need any layer 2s because we could just make on-chain payments. However, we live in the real world and have a 1mb block size limit, and this limits the number of transactions we can make on-chain. Lightning is a huge improvement to bitcoin because we don't need to put _every_ transaction on-chain, we just need to open a channel and can make seemingly countless payments. So why isn't lightning the silver bullet? Lightning lets us move payments off-chain but what it doesn't do is let us move ownership off-chain. Fundamentally lightning still relies on that, at the end of the day, a utxo goes to single user. So even if every on-chain transaction was a lightning channel, we still run into the limit of how many people can actually own those channels. What we need is another layer 2 that can scale utxo ownership and caninterop with lightning, that way we have a way to scale ownership combined with scaling payments.
So how do we scale ownership? Simply put, the answer today is custody, whether that is pure custodial like a Wallet of Satoshi or in the grey area like fedimints and liquid, the only way to do it today is through custody or federated bridges. In bitcoin, the only way to delegate ownership of a utxo to multiple parties is through multisig, however, that requires every user to be online when anyone wants to transact, and when you take go down this path far enough you end up just reinventing lightning.
Are we doomed then? Is there no way to scale bitcoin in a self-sovereign way? Luckily, the answer is no, but we need some soft-forks. Covenants are the way to scale bitcoin ownership. There are a bunch of covenant proposals but at their core what they propose to do is to add a way, so you can have a bitcoin address that limits where and how the coins in it can be spent. This can seem scary, but we already have these in bitcoin today, OP_CTLV (Check LockTime Verify), which was soft forked in 2016, only allows you to spend from a bitcoin address if the transaction has a given locktime, this lets you gate _when_ a utxo can be spent. What the current covenant proposals do is let you gate _where_ a utxo can be spent. With that simple primitive many different protocols can be built that allow for scaling ownership.
There are a lot of current covenant proposals, the main ones being: OP_CTV, OP_VAULT, OP_CSFS, OP_TXHASH, OP_CAT, and APO. They all have different functionality and tradeoffs but in my opinion we should be looking towards activating a form of covenants because otherwise we will likely be moving towards a future of less sovereign bitcoin users.
The future is not bleak however, even without covenants we can still scale bitcoin for the world, just not in the ideal way. At Mutiny, we are full steam ahead on implementing fedimint into the wallet, in my opinion (and the rest of the team's) it looks like the best current scaling solution for bitcoin. Fedimints give us the ability to dynamically share ownership over a group of utxos and is able to interop with lightning through gateways. It is the pinnacle of the scaling dream for bitcoin with current technology and I can't wait to help make it reality while we can.
-
@ e1ff3bfd:341be1af
2023-12-17 18:49:31
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.
-
@ e1ff3bfd:341be1af
2023-12-10 19:28:38
Ever since the infamous Taproot Wizard 4mb block bitcoiners have been alight, fighting to try and stop inscriptions. Inscriptions are *definitely* not good for bitcoin, but how bitcoiners are trying to stop them will be far worse than any damage inscriptions could have ever caused.
Inscriptions work by embedding images or other data into the bitcoin blockchain by using a trick in bitcoin script. They essentially put the data in an unreachable code block followed by the real spending conditions so the user can claim the ordinal/NFT. It is quite an ingenious trick but has broke a lot of the assumptions many bitcoiners were operating under. Previously, the main way to embed data into bitcoin was OP_RETURN, which is basically an op code exactly meant for embedding data but had two problems for the NFT people: it makes coins unspendable and by mempool policy is limited to 80 bytes. Inscriptions has the advantage that their only size limit is the block size and since their data is in the witness, not the output, they benefit from the witness discount, allowing them to embed 4x the data. This broke a lot of bitcoiners assumptions that the theoretical 4mb block would never happen because it'd be silly to have only witness data, however, the NFT people found a way to monetize it. Now this is common place and we've seen tons of inscriptions happen, driving up fees and block sizes.
Inscriptions are an attack on bitcoin. Inscriptions are not going to kill bitcoin, but none the less, it is an attack. Exploiting a trick in bitcoin script to use the witness discount for embedding data is definitely hurting the network, blocks were never meant to actually reach the theoretical limit and it is a problem that it is happening. Nodes will be more expensive to run and this will hurt decentralization of the network. However, now that it is happening and common place, we cannot stop it.
In retaliation bitcoiners are proposing ways to "stop" inscription and these will do far worse damage then inscriptions will ever do. Almost every proposal to stop inscriptions boils down to preventing these transactions from getting into the mempool. The mempool is the battle ground of bitcoin transactions and we need to preserve it. The mempool only works if it the premier way to get the highest fee rate transactions to miners. If we lose that guarantee, people will move to centralized systems and we may never get the mempool back. Filtering spam transactions from the mempool will not stop inscriptions, at best it will delay them by a week. The people buying inscriptions are morons, but the people selling them are not, they already have back channel communications with mining pools and if we cut them off from the mempool, then the only pools getting these fees will be the shitcoin aligned pools. This has already happened to many shitcoin networks where their mempool was killed off for one reason or another and now the primary way to broadcast a transaction is through a centralized api. This essentially creates a permissioned network, where even if anyone can run a node, if you don't have access to the transaction broadcasting api, you cannot access bitcoin. We are currently seeing congress try harder and harder to regulate nodes, miners, and wallets as money transmitters and losing the mempool will make this problem 1000x worse. There is also serious security problems without being able to do trustless fee estimation if we lose the mempool, but that is out of scope of this post.
Further, filtering transactions based on "spam" metrics can lead us down a dark path. The most economical way to transact in bitcoin is *not* the most private. Today the most popular way to get privacy for your on-chain bitcoin is doing a coinjoin. Coinjoins are not necessarily economic transactions, you are merely spending to yourself along with a bunch of other people. If we set precedent that you have to justify the usefulness of your transaction to not be considered spam, soon people will find a way to exploit this to try and get coinjoins and other privacy techniques excluded from mempools for being spam.
With all this being said, if bitcoin is going to work, we shouldn't need to care about inscriptions. The promise of bitcoin is a global monetary network backing the entire financial world, if that is overtaken and its primary use case is a NFT trading platform, then bitcoin was doomed to fail in the first place. We have seen many shitcoin bubbles for over the past decade and this one is no different. The shitcoiners will eventually run out of fools to buy their scam and things will go back to normal, but we can't shoot our self in the foot trying to stop things prematurely, when we can just wait them out.
#SaveTheMempool