Channels without HTLCs

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.