ZmnSCPxj » Activity » 2019-12-26 Weekly Log

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:

  1. You send out a multi-hop payment.

  2. Before the payment reaches the final destination, miners are able to find a block.

  3. The block propagates over the network faster than your payment does, because of Bitcoin FIBRE, or because some of the forwarding nodes are flaky.

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