Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
lightning network improved
HTLCs below the dust limit are not possible, because they're uneconomical.
So currently whenever a payment below the dust limit is to be made Lightning peers adjust their commitment transactions 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).
SOLUTION
I didn't think too much about if it is possible to do what I think can be done in the current implementation on Lightning channels, but in the context of Eltoo it seems possible.
Eltoo channels have UPDATE transactions that can be published to the blockchain and SETTLEMENT transactions that spend them (after a relative time) to each peer. The barebones script for UPDATE transactions is something like (copied from the paper, because I don't understand these things):
OP_IF
# to spend from a settlement transaction (presigned)
10 OP_CSV
2 As,i Bs,i 2 OP_CHECKMULTISIGVERIFY
OP_ELSE
# to spend from a future update transaction
<Si+1> OP_CHECKLOCKTIMEVERIFY
2 Au Bu 2 OP_CHECKMULTISIGVERIFY
OP_ENDIF
During a payment of 1 satoshi it could be updated to something like (I'll probably get this thing completely wrong):
OP_HASH256 <payment_hash> OP_EQUAL
OP_IF
# for B to spend from settlement transaction 1 in case the payment went through
# and they have a preimage
10 OP_CSV
2 As,i1 Bs,i1 2 OP_CHECKMULTISIGVERIFY
OP_ELSE
OP_IF
# for A to spend from settlement transaction 2 in case the payment didn't went through
# and the other peer is uncooperative
<now + 1day> OP_CHECKLOCKTIMEVERIFY
2 As,i2 Bs,i2 2 OP_CHECKMULTISIGVERIFY
OP_ELSE
# to spend from a future update transaction
<Si+1> OP_CHECKLOCKTIMEVERIFY
2 Au Bu 2 OP_CHECKMULTISIGVERIFY
OP_ENDIF
OP_ENDIF
Then peers would have two presigned SETTLEMENT transactions, 1 and 2 (with different signature pairs, as badly shown in the script). On SETTLEMENT 1, funds are, say, 999sat for A and 1001sat for B, while on SETTLEMENT 2 funds are 1000sat for A and 1000sat for B.
As soon as B gets the preimage from the next peer in the route it can give it to A and them can sign a new UPDATE transaction that replaces the above gimmick with something simpler without hashes involved.
If the preimage doesn't come in viable time, peers can agree to make a new UPDATE transaction anyway. Otherwise A will have to close the channel, which may be bad, but B wasn't a good peer anyway.
2019-04-30
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.

Lightning Network: reclaiming the original vision

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).

Description

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:

  1. It isn't based on credit or trust. Instead, the balances are based on money deposited upfront
  2. 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).

Solution

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment