2023 Mar 08
Never knew the
::<Type>
syntax was called turbofish.Main idea: If we have any public channels, we don’t need route hints. However if we recently opened a public channel, it won’t be announced for 6 confirmations (and propagated for probably 7), during which we would not provide route hints, even though the sender doesn’t know about this channel.
What is a route hint? BOLT 11 invoices include tagged fields for data related to the payment, one of which is
r
, for route hints. A route hint is just information about a channel for nodes that are only accessible through private channels.Channel announcement requires funding tx to have 6 confirmations? Yep.
We refuse to include route-hints if we have any public channels? Yep.
Never knew the precise fields relating to fees, but for a channel update (complements announcement, provides information about relaying HTLCs using this channel for a particular node) there’s
fee_base_msat
andfee_proportional_millionths
Formula for fee:
fee_base_msat + ( amount_to_forward * fee_proportional_millionths / 1000000 )
Did not realize how many edge cases there are for route hints
Wow finally got fzf integrated in my shell. Amazing
Forgot this, but pathfinding is performed (by the sender) from the recipient back to the sender. Why? Because if we are trying to pay someone, we typically want them to receive that exact amount, and we will pay extra for fees on top of that. If we want to do something like send our remaining wallet amount somewhere, i.e. find a route given a sending amount, routing from the receiver to the sender makes things a bit more difficult.
- Was thinking why don’t we just route from the source in cases like this? Discovered minimum-cost flow problem which is pretty much exactly this. There are apparently ways to solve this efficiently but I realized it’s probably more work to maintain two routing implementations than it is to approximate with a couple passes from destination to source (routing value - predicted fee).
What are short_chan_id aliases and why do I always see comments about them?
Beginning review on this PR
This issue is mainly concerned with
ChannelDetails::outbound_capacity_msat
being inaccurate, which just straight up leads to failed payments, but is also important for any further routing magic, including finding a route given a sending amount which I mentioned above.There are several checks that need to be added, but this PR tackles one of them.
What prevents channels from misreporting capacity and inflating the money supply? Must point to block number txid output index