The title is a joke because I have no idea of what was the original vision, but this at least corresponds to some vision from someone (me).
In the current Lightning Network it's not safe to send or relay small payments because the cost of settling these payments onchain in case of failure is too big.
The way the current design solves this is that according to node preferences, whenever a payment below some threshold is sent through a channel the commitment transaction is adjusted to pay that amount as fees in case the channel is closed. That's a form of reserving that amount and incentivizing peers to resolve the payment, either successfully (in case it goes to the receiving node's balance) or not (it then goes back to the sender's balance).
Since onchain fees are expected to rise (and rise they must if Bitcoin is to continue working) then the above can become a problem as most or all Lightning transactions are deemed uneconomical and sent not through real HTLCs redeemable onchain but just as fake HTLCs which are just fees to miners.
Against the argument that such a construction is not trustless it has been argued that a channel is a valuable entity that both peers wouldn't want to close just to make the other party lose money, with which I agree. Problem
The Lightning Network resembles a lot the idea of sending payments through mutual credit networks, an idea that has been tried many times in the past starting with Ryan Fugger's Ripple (before he sold the name to the Ripple shitcoin) but never worked out because no one has came up with a way to solve the decentralized commit problem (and embarrassingly people keep reviving the idea without acknowledging this issue which was already stated in the old Ripple documents).
In short, the problem is that the payment is done in parts, A pays B, B pays C, C pays D and so on (or in the reverse order), but if one of the payments fails or is delayed the entire thing is left half-committed, in an undecided state, and there's not even a way to know when peers should safely say a payment has failed or it's still pending.
Like Lightning, these networks work with payments going through routes passing through channels and altering the balances of these channels. However Lightning does two things these mutual credit networks don't do:
- It isn't based on credit or trust. Instead, the balances are based on money deposited upfront
- It solves the decentralized commit problem with HTLCs that can be redeemed the Bitcoin blockchain with clear timeouts and exposing (or not, depending on who redeemed) preimages that work as proofs of payment and can be used by the remaining pending hops in a route
However, if the Lightning Network suddenly starts working without real HTLCs then the second advantage doesn't hold anymore, we will be living in a world of undecided transactions with no proof-of-payment.
For example: if D gets a payment proposal from C it then releases a proof-of-payment. At that point, before sending an updated commit transaction to D, C can stop answering D but still use the proof-of-payment to resolve the payment it has pending from B and B can do the same with A, so A will have a proof-of-payment but D won't be received anything.
If following the current Lightning spec, D will then proceed to close his channel with C to redeem the HTLC onchain – however there's no real HTLC to be redeemed, the C–D channel will be closed for no reason – or rather for the reason that C was a terrible peer anyway, but that's not the way the network was supposed to work (there's a claim a payment network could work this way, but then it would be another iteration of mutual credit networks and not Lightning anymore).
The solution is to make payments in Lightning atomic and conditional, with proof-of-payment, but without increasing the onchain overhead by a lot.
The idea is that each payment in-flight would conditionally alter the final balance instead of add a new output and require a new transaction to be redeemed. The final balance is still a single transaction that closes the channel.
This way there's no incentive at all to skip adding the relevant conditions and fulfillments to each channel. Lightning keeps its two basic promises: trustlessness through a fair split of predeposited coins (minus fees) and a decentralized commit enforced by hashlocks.
A prototype of how this can be implemented on Eltoo is shown here: https://gist.github.com/fiatjaf/712a8651dff5908d139dc62ea4dfd551#file-hashlocked-updates-eltoo-svg
2020-02-29