> 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.
Replies (5)
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