[Lightning-dev] Per-hop forwarding fees

Anthony Towns aj at erisian.com.au
Thu Sep 24 08:31:21 UTC 2015

Hi all,

So as was discussed last month [0] there's a potential incentive problem
if fees are only paid on success: you can lock up someone else's funds for
"TIMEOUT" and pay them nothing, just by routing a payment to someone who
won't either collect it, or redeem it. As an alternative to fines [1]
I think it's possible to offer fees directly for forwarding a transaction.

Suppose you have an onion wrapped routing message, and want to send N
bitcoins to Dave via Alice, Bob and Carol. Alice receives message MA,
Bob receives MB, etc. Alice wants "a" in fees, Bob wants "b" in fees,
etc. Then you setup HTLCs paying A as follows:

  "c/2+n"   bitcoins payable on receipt of R
  "c/2+b/2" bitcoins payable on receipt of #(MD)
  "b/2+a/2" bitcoins payable on receipt of #(MC)
  "a/2"     bitcoins payable on receipt of #(MB)

Alice forwards MB to Bob (encrypted), and asks if Bob is able to determine
what hashes to #(#(MB)). Bob calculates #(MB) and #(#(MB)) and gives an
ack or nak -- if there's a nak, Alice aborts the transaction. If it's
an ack, Bob begins updating the commitments to add (c/2+n), (c/2+b/2),
(b/2) HTLCs with Alice payable to Bob, and provides #(#(MB)) to Alice,
allowing her to collect the first half of her fee.

This then repeats for Bob/Carol and Carol/Dave.

This lets nodes get paid upfront (when they forward the transaction,
rather than when the transaction eventually completes), including for
failing transactions, but requires them to actually do 90% of the work
forwarding the transaction (Alice can abort accepting the HTLCs with
Bob, but Alice will miss out on half her fee, and Bob will know Alice
is cheating him out of "b" bitcoins at that point, and can close the
channel as punishment). It also gives the payer some progress information
on how the transaction is doing (the "a" transaction should be finished
shortly after the transaction has made it to Bob, etc).

Downsides: it's complicated and multiplies the number of HTLCs you have
to deal with, and it (at least somewhat) reveals the length of the route.

(If incremental fines work out, I think they're probably a better way
of dealing with delayed acceptance of transactions. Still, maybe this
turns out to be useful/interesting anyway...)


[0] http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-August/000135.html


More information about the Lightning-dev mailing list