BOLT 4: Report outgoing HTLC values when appropriate#538
Conversation
For some relaying errors it makes more sense to report the values of the outgoing HTLC rather than the incoming HTLC.
...and found bugs! Note that there is something fishy in BOLT 4, filed a PR: lightning/bolts#538 Also, first try of softwaremill's quicklens lib (in scope test for now)
|
Isn't this backwards incompatible? Do we want to just append the outgoing value instead? |
|
@pm47 can you spell out the rationale for this change? If a node gives you an HTLC with an incorrect value, and the the onion checked, then why is it useful to send back the onion data to the sending node? Whereas right now, we'd send back the incorrect htlc value that was extended. |
Technically yes but I really don't think that's a big deal, those values are just reported as hints and I don't think any implementation does anything more than display or log them.
In the following scenario Also, I think that was clearly the intent of the spec, because if you look at the very similar |
Roasbeef
left a comment
There was a problem hiding this comment.
LGTM
lnd does this already, just felt more natural when coding it up
* relay to channel with lowest possible balance Our current channel selection is very simplistic: we relay to the channel with the largest balance. As time goes by, this leads to all channels having the same balance. A better strategy is to relay to the channel which has the smallest balance but has enough to process the payment. This way we save larger channels for larger payments, and also on average channels get depleted one after the other. * added tests... ...and found bugs! Note that there is something fishy in BOLT 4, filed a PR: lightning/bolts#538 Also, first try of softwaremill's quicklens lib (in scope test for now) * minor: fixed typo (h/t @btcontract)
For some relaying errors it makes more sense to report the values of the outgoing HTLC rather than the incoming HTLC.