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
of pay on C-Lightning, where it started with a large
route randomization fuzzpercent, then lowers it if the
maxfeepercent or 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 final_expiry_too_soon
A recent
change in BOLT 4 merged the final_expiry_too_soon
failure code into the incorrect_or_unknown_payment_details
failure code.
The problem is that final_expiry_too_soon did not have
the 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
events:
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 PERM
bit set.
Because that bit is not set, it was not considered a permanent error,
and thus the pay implementation would retry in that
situation.
However, the linked commit in lightning-rfc requires that we now
use incorrect_or_unknown_payment_details to report this
failure case.
incorrect_or_unknown_payment_details has the
PERM bit set, meaning it is now classified as a permanent
failure.
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
errors).
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.
If incorrect_or_final_payment_details is the failure
code returned, we should try to check if the returned height
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.
Rust Studying
Unfortunately, no activity here at all.