Thread

What's the biggest hurdle to making lightning easier to use?

LSP integration and closing the loop on things like 0FC, splicing, and async payments (all of which are in LDK 0.2, but gotta get broad support for some of them).

I think Spillman channels are an ideal format for onboarding to and offboarding from lightning because most last-mile use cases are one way payment flows. The average Joe receives a paycheck -> spends it down -> receives another one. Likewise for merchants: receive payments -> empty register -> receive more payments. Unidirectional channels also match miner & pool flows for the same reason, which is the primary driver of my interest in Spillman channels. Probably the fastest path to adoption is to apply the ark protocol. Seems like they already manage batched channel renegotiations nicely. Very interested to see what protocols come out of Second & Ark Labs and how they can be applied to mining pool payouts. Unified liquidity management at the LN node level would enable users to dump their Spillman channel liquidity into a lightning channel before the timeout. This effectively creates a unilateral channel close option for the sender in a Spillman channel and dramatically improves the usability of those channels. Very similar to how bitcoin dramatically improves the usability of ecash. In both cases, they were just invented in the wrong order. You raise a really great point, though. Do we need Spillman HTLCs to unify Spillman & Poon-Dryja channel liquidity? 🤔 I'll have to think on that one.

> The average Joe receives a paycheck -> spends it down -> receives another one. Likewise for merchants: receive payments -> empty register -> receive more payments. What you just described is not a “unidirectional” payment flow, but rather a bidirectional one. Yes, you can substantially increase your on-chain/Ark liquidity footprint and emulate bidirectional with unidirectional channels but it adds cost. More importantly, you didn’t actually address my point - the complexity difference is not nearly as big as people seem to think. There’s no “advantage” to spillman channels in the sense that they are strictly less flexible and as a result have higher on-chain footprint or higher liquidity cost for an Ark LSP (which in turn means higher cost for the wallet owner). The only reason to use them over Lightning (even in Ark) would be if there were some huge software engineering complexity advantage, but there is not. The stated advantages are: * the on-disk size is smaller, but you save a few MB, at max. So what? The complexity in lightning is that you have critical on-disk storage to begin with, not that it’s big. Spillman channels have the same. * you don’t have to monitor the chain for closures, but this doesn’t help you at all in an Ark - you already have much much stricter online requirements in Ark than Lightning, so you net no advantage. > You raise a really great point, though. Do we need Spillman HTLCs to unify Spillman & Poon-Dryja channel liquidity? 🤔 I'll have to think on that one. Yes, which is very nontrivial, suddenly your “one-way” channel isn’t one way.

Spillman doesn't suffer from the liveness requirement and therefore the attack surface of lightning. No toxic data to protect. Also, the LN protocol implementors made a (IMO grave) mistake replicated in many places by most btc protocol devs of ignoring mining. In lightning's case even overloading miners with an additional and uncomplementary role: low value HTLCs are escrowed by miners. This opens a fundamental protocol vulnerability where bitcoin block producers who run a LN node can jam a channel with low value HTLCs, take their node offline, and mine the force close tx themselves, stealing from their channel counterparties. If we're serious about decentralizing mining as a community we need to think long and hard about a world where anyone can mine a tx permissionlessly. I think lightning in it's current form is not suited to task for mining pool payouts. Real talk: ecash is the perfect tool for low value fees. I think it has a place in LN and BTC protocols. I intend to pursue on-chain ecash tx fees. Not sure if it's worth it to pursue fixing LN fees. I think it's probably way easier to just use other L2 protocols that are less broken and less entrenched. But we'll see. I'm always open to change my mind in light of new evidence. In any case, if we are successful in decentralizing mining the LN protocol will have to adapt to the new reality. I don't see any other way forward for bitcoin.

Edit for clarity: ecash fees for on-chain txs

Use amethyst. It has an edit button. But other clients don't pick up edits.

Gah, more edits: "Not sure if it's worth it to pursue fixing this low value HTLC protocol vulnerability."

I tapped the original post out on my phone while making coffee lol

> Spillman doesn't suffer from the liveness requirement and therefore the attack surface of lightning. No toxic data to protect. Two points. I raised above when you were talking about spillman in the context of Ark that this doesn’t matter - you still have the same liveness requirement. Worth noting that the “toxic data” problem isn’t a problem cause of the “toxic” part, but rather because bitcoiners are used to wallets that do not store anything - copy your seed into a different wallet and all your moneys there! Spillman doesn’t fix that, it only fixes the liveness part (as long as it’s not on Ark). Of course if you want to interoperate with LN/HTLCs suddenly you’re back to square one. > Also, the LN protocol implementors made a (IMO grave) mistake replicated in many places by most btc protocol devs of ignoring mining. In lightning's case even overloading miners with an additional and uncomplementary role: low value HTLCs are escrowed by miners. This opens a fundamental protocol vulnerability where bitcoin block producers who run a LN node can jam a channel with low value HTLCs, take their node offline, and mine the force close tx themselves, stealing from their channel counterparties. There are plenty of issues with LN, the cost of on-chain HTLC claims is certainly one, but it’s not unique in any way to miners - whether they pay the tx fee directly or in opportunity cost doesn’t really matter. > If we're serious about decentralizing mining as a community we need to think long and hard about a world where anyone can mine a tx permissionlessly. 💯 > I think lightning in its current form is not suited to task for mining pool payouts. I mean, maybe? Nice thing is everything is interoperable these days. Pool pays out lightning, miner receives ecash, Ark, Spark, LN, or whatever they want 🤷‍♂️ > Real talk: ecash is the perfect tool for low value fees. I think it has a place in LN and BTC protocols. I intend to pursue on-chain ecash tx fees. Not sure if it's worth it to pursue fixing LN fees. I think it's probably way easier to just use other L2 protocols that are less broken and less entrenched. But we'll see. I'm always open to change my mind in light of new evidence. I’m honestly lost at your claim here??? LN fees are strictly lower than on-chain. > In any case, if we are successful in decentralizing mining the LN protocol will have to adapt to the new reality. I don't see any other way forward for bitcoin. Similarly, absolutely entirely lost at what you’re even talking about.

I appreciate your unique perspective from actually building these solutions. Glad you're on nostr to discuss it. 💜 How do ark spillman channels carry a liveness requirement? Can the ASP double spend your VTXO input while you're offline? I was under the impression they couldn't do that. In my mental model you can get a Spillman VTXO with a 4 week timeout, go offline without worry for up to 3 weeks and 6 days. Then you just refresh the timeout once and go back offline. If the ASP "force closes" on you, there's nothing to do since your VTXO goes on chain, you already got your money out. I might be mistaken, though. I have studied lightning a lot more than ark. (Shoutout Chaincode! 🙌) Compare this with lightning where your counterparty broadcasts a tx and you don't know the timer to act has started unless you're actively monitoring the blockchain. Once you find out, you now have to get a tx mined to protect yourself, which is a whole new set of problems. This can be delegated to a watchtower but it requires a lot more active monitoring. This is why I believe the liveness requirements are harder to manage for lightning. But you're right that spillman-ark also has a liveness requirement. > whether they pay the tx fee directly or in opportunity cost doesn’t really matter. Are you talking about the opportunity cost of closing a LN channel? The cost to spend low value HTLC outputs in this attack is mitigated because all the low value HTLC fee outputs are rolled up into the coinbase, which is effectively a single tx input. This is a unique advantage for miners. > Nice thing is everything is interoperable these days. Yeah lightning has really matured into the connective tissue of the whole bitcoin network. It's an amazing achievement. Y'all have a lot to be proud of. > I’m honestly lost at your claim here??? > Similarly, absolutely entirely lost at what you’re even talking about. I didn't explain fully because there's a lot there. But TL;DR I think there is a tremendous amount of potential in exogenous transaction fees. I want to build a permissionless bitcoin tx accelerator network to compete with existing mining pool closed APIs (in fact, I think it's necessary for a decentralized bitcoin network). We can make a trust tradeoff to enable ecash tx fees. You have to trust the mint to pay out the fees but with ecash privacy properties and low value payments it can work well in practice. This solves a ton of problems in L2 protocol design. We can finally realize the dream of permissionlessly fee bumping any bitcoin transaction without the restrictions of RBF or CPFP. A lot of the insane policy rules can be circumvented. We still need to be careful about the more sane policy filters like dust outputs, bare script, etc. The worst of these can be mitigated with GCC. Exogenous fees work for LN too. Imagine we updated the LN protocol to escrow low value payments with ecash instead of mining pools. The low value HTLC protocol vulnerabilities go away. Rug risk is minimal because fees are low and reputation is hard to earn and easy to burn. Ecash supports HTLCs so we could possibly even remove them from the commitment transaction entirely. I haven't thoroughly explored these ideas but I believe there is A LOT of potential in this concept.