2019-12-20 to 2019-12-26
Unfortunately, relatively low activity this week. It seems likely to also have low activity for a few more weeks due to various pre-scheduled circumstances.
Path Privacy on Lightning
As mentioned in previous log, this is something I have taken an interest in. I have created a lengthy article on lightning-dev regarding this topic.
This includes a number of various possible improvements that might help payment privacy on Lightning.
Another thing I am working on is returning the previous behavior
pay on C-Lightning, where it started with a large
fuzzpercent, then lowers it if the
maxdelay have been violated.
While I have coded this already, creating a test for this has
been delayed somewhat, due to the next item.
BOLT Regression on
change in BOLT 4 merged the
failure code into the
The problem is that
final_expiry_too_soon did not have
PERM bit set.
This means it is not a permanent error, which makes sense.
The most usual cause of this error is the following sequence of
You send out a multi-hop payment.
Before the payment reaches the final destination, miners are able to find a block.
The block propagates over the network faster than your payment does, because of Bitcoin FIBRE, or because some of the forwarding nodes are flaky.
The payment reaches the final destination, which now has fewer blocks to claim its payment.
The above sequence of events is very unlikely, but is still a possible edge case.
Before, this was handled “normally” by C-Lightning
(and presumably other implementations) because
final_expiry_too_soon did not have the
Because that bit is not set, it was not considered a permanent error,
and thus the
pay implementation would retry in that
However, the linked commit in lightning-rfc requires that we now
incorrect_or_unknown_payment_details to report this
incorrect_or_unknown_payment_details has the
PERM bit set, meaning it is now classified as a permanent
Because this failure is now a permanent failure, the
pay implementation will not retry — after all,
the failure is marked as permanent!
But in fact this sub-case is actually a transient problem that
should eventually get fixed once the payer node catches up to
the latest blockchain state.
The Real Bug is that we are now reporting a transient problem
using a failure code that has the
PERM bit set,
which is inaccurate (because that should only be set for permanent
Of course, having this as a separate failure code lead to
privacy leaks, so we are forced to accept this now-permanent
failure code for a transient problem.
Fortuitously Nicolas Dorier had a test case that tickled this edge case, and reported it in C-Lighntning#3367.
The solution is to special-case this failure mode.
incorrect_or_final_payment_details is the failure
code returned, we should try to check if the returned
is higher than the height before we sent the payment.
The returned height is the block height that the destination knows.
If the destination has a higher block height than what the block
height was before we sent the payment, we should instead
consider it as this previously-non-permanent failure.
Unfortunately, no activity here at all.