{"type":"rich","version":"1.0","author_name":"npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2h","author_url":"https://nostr.ae/npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2h","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2022-06-29\n📝 Original message:\nOn Sun, Jun 05, 2022 at 02:29:28PM +0000, ZmnSCPxj via Lightning-dev wrote:\n\nJust sharing my thoughts on this.\n\n\u003e Introduction\n\u003e ============\n\u003e           Optimize for reliability+\n\u003e            uncertainty+fee+drain+uptime...\n\u003e                  .--~~--.\n\u003e                 /        \\\n\u003e                /          \\\n\u003e               /            \\\n\u003e              /              \\\n\u003e             /                \\\n\u003e         _--'                  `--_\n\u003e         Just                  Just\n\u003e       optimize              optimize\n\u003e         for                   for\n\u003e       low fee               low fee\n\nI think ideally you want to optimise for some combination of fee, speed\nand reliability (both liklihood of a clean failure that you can retry\nand of generating stuck payments). As Matt/Peter suggest in another\nthread, maybe for some uses you can accept low speed for low fees,\nwhile in others you'd rather pay more and get near-instant results. I\nthink drain should just go to fee, and uncertainty/uptime are just ways\nof estimating reliability.\n\nIt might be reasonable to generate local estimates for speed/reliability\nby regularly sending onion messages or designed-to-fail htlcs.\n\nSorry if that makes me a midwit :)\n\n\u003e Rene Pickhardt also presented the idea of leaking friend-of-a-friend balances, to help payers increase their payment reliability.\n\nI think foaf (as opposed to global) gossip of *fee rates* is a very\ninteresting approach to trying to give nodes more *current* information,\nwithout flooding the entire network with more traffic than it can\ncope with.\n\n\u003e Now we can consider that *every channel is a marketplace*.\n\u003e What is being sold is the sats inside the channel.\n\n(Really, the marketplace is a channel pair (the incoming channel and\nthe outgoing channel), and what's being sold is their relative balance)\n\n\u003e So my concrete proposal is that we can do the same friend-of-a-friend balance leakage proposed by Rene, except we leak it using *existing* mechanisms --- i.e. gossiping a `channel_update` with new feerates adjusted according to the supply on the channel --- rather than having a new message to leak friend-of-a-friend balance directly.\n\n+42\n\n\u003e Because we effectively leak the balance of channels by the feerates on the channel, this totally leaks the balance of channels.\n\nI don't think this is true -- you ideally want to adjust fees not to\nmaintain a balanced channel (50% on each side), but a balanced *flow*\n(1:1 incoming/outgoing payment volume) -- it doesn't really matter if\nyou get the balanced flow that results in an average of a 50:50, 80:20\nor 20:80 ratio of channel balances (at least, it doesn't as long as your\nchannel capacity is 10 or 100 times the payment size, and your variance\nis correspondingly low).\n\nFurther, you have two degrees of freedom when setting fee rates: one\nis how balanced the flows are, which controls how long your channel can\nremain useful, but the other is how *much* flow there is -- if halving\nyour fee rate doubles the flow rate in sats/hour, then that will still\nincrease your profit. That also doesn't leak balance information.\n\n\u003e ### Inverting The Filter: Feerate Cards\n\u003e Basically, a feerate card is a mapping between a probability-of-success range and a feerate.\n\u003e * 00%-\u003e25%: -10ppm\n\u003e * 26%-\u003e50%: 1ppm\n\u003e * 51%-\u003e75%: 5ppm\n\u003e * 76%-\u003e100%: 50ppm\n\nFeerate cards don't really make sense to me; \"probability of success\"\nisn't a real measure the payer can use -- naively, if it were, they could\njust retry at 1ppm 10 times and get to 95% chances of success. But if\nthey can afford to retry (background rebalancing?), they might as well\njust try at -10ppm, 1ppm, 5ppm, 10ppm (or perhaps with a binary search?),\nand see if they're lucky; but if they want a 1s response time, and can't\nafford retries, what good is even a 75% chance of success if that's the\nindividual success rate on each hop of their five hop path?\n\nAnd if you're not just going by odds of having to retry, then you need to\nget some current information about the channel to plug into the formula;\nbut if you're getting *current* information, why not let that information\nbe the feerate directly?\n\n\u003e More concretely, we set some high feerate, impose some kind of constant \"gravity\" that pulls down the feerate over time, then we measure the relative loss of outgoing liquidity to serve as \"lift\" to the feerate.\n\nIf your current fee rate is F (ppm), and your current volume (flow) is V\n(sats forwarded per hour), then your profit is FV. If dropping your fee\nrate by dF (\u003c0) results in an increase of V by dV (\u003e0), then you want:\n\n   (F+dF)(V+dV) \u003e FV\n   FV + VdF + FdV + dFdV \u003e FV\n   FdV \u003e -VdF\n   dV/dF \u003c -V/F (flip the inequality because dF is negative)\n\n   (dV/V)/(dF/F) \u003c -1  (fee-elasticity of volume is in the elastic\n                        region)\n\n(\u003c-1 == elastic == flow changes more than the fee does == drop the fee\nrate; \u003e-1 == ineleastic == flow changes less than the fee does == raise\nthe fee rate; =-1 == unit elastic == you've found a locally optimal\nfee rate)\n\nYou could optimise base fee in the same way, if you set F to be sats/tx\nand V to be txs/hour, but then you're trying to optimise two variables\non a 2 dimensional plane, which is harder. So probably better to do\nzero base fees and just set it to 0 and ignore it, or use your actual\ncomputation costs -- perhaps about 20msat if you're paying $100USD/month\nfor your lightning node, a channel update takes 10ms, each forwarded HTLC\naccounts for 4 updates, 2 on the incoming channel, 2 on the outgoing,\nwith no batching, and only 40% of payments are successful, at $20k/BTC.\n\nIt's likely more important to have balanced flows than maximally\nprofitable ones though, as that's what allows you to keep your channel\nopen. That's probably pretty hard to optimise, since a changed fee on\none channel will affect the volume on ther channels as well.\n\nRelatedly:\n\n\u003e I want to propose that all published nodes support some kind of\n\u003e onchain/offchain swap capability.\n\nIf you're running a forwarding node, and collecting fees for forwarding,\nconsidered in net your channels won't be balanced: the fees you collect\nare all coming in, and there's nothing to compensate for that. Having some\nway to send those fees \"out\" is necessary to keep your channels balanced\nand avoid the need to have to close them. Having a swap capability like\nthis is perhaps a relatively easy way to be able to (automatically)\nfix imbalances caused by collecting fees, and thus preserve your older\nchannels.\n\nCheers,\naj"}