Browse Source
follow-up https://github.com/spesmilo/electrum/pull/7818 - note it matters whether a sender pays us end-to-end-trampoline or just via legacy - consider: Alice has 0.1 BTC recv cap in chan1 and 1 BTC recv cap in chan2, both with border-node T1 - if sender is paying e2e trampoline, it can realistically pay even ~1.1 BTC, as T1 can resplit the HTLCs - if sender is paying legacy, it will have a hard time trying to pay more than 1 BTC, in practice - although note if T1 has implemented non-strict-forwarding (see BOLT-04), achieving 1 BTC is easy, as T1 can redirect HTLCs (but cannot split them, in this case) - to make num_sats_can_receive realistic, it assumes the legacy case - To calc num_sats_can_receive, we sort our channels in decreasing order of receive-capacities, iterate over them and calculate a running sum - we stop adding channels when the next chan's recv cap is small compared to the running total. - When putting routing hints in an invoice, we do the same, with the added condition that we keep adding channels if their recv cap is larger than the invoice amount. - consider: Alice has 0.1 BTC recv cap in chan1 with Bob, and 1 BTC recv cap in chan2 with Carol - if Alice wants to recv 100 sats, it is useful to add hints for both channels into the invoice, for redundancy - if Alice wants to recv 0.9 BTC, it is questionable whether adding the smaller chan is useful - the code here won't add itpatch-4
SomberNight
3 years ago
2 changed files with 43 additions and 39 deletions
Loading…
Reference in new issue