rich1.0npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2hhttps://nostr.ae/npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2hnjumphttps://nostr.ae📅 Original date posted:2022-06-29 📝 Original message: On Sun, Jun 05, 2022 at 02:29:28PM +0000, ZmnSCPxj via Lightning-dev wrote: Just sharing my thoughts on this. > Introduction > ============ > Optimize for reliability+ > uncertainty+fee+drain+uptime... > .--~~--. > / \ > / \ > / \ > / \ > / \ > _--' `--_ > Just Just > optimize optimize > for for > low fee low fee I think ideally you want to optimise for some combination of fee, speed and reliability (both liklihood of a clean failure that you can retry and of generating stuck payments). As Matt/Peter suggest in another thread, maybe for some uses you can accept low speed for low fees, while in others you'd rather pay more and get near-instant results. I think drain should just go to fee, and uncertainty/uptime are just ways of estimating reliability. It might be reasonable to generate local estimates for speed/reliability by regularly sending onion messages or designed-to-fail htlcs. Sorry if that makes me a midwit :) > Rene Pickhardt also presented the idea of leaking friend-of-a-friend balances, to help payers increase their payment reliability. I think foaf (as opposed to global) gossip of *fee rates* is a very interesting approach to trying to give nodes more *current* information, without flooding the entire network with more traffic than it can cope with. > Now we can consider that *every channel is a marketplace*. > What is being sold is the sats inside the channel. (Really, the marketplace is a channel pair (the incoming channel and the outgoing channel), and what's being sold is their relative balance) > 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. +42 > Because we effectively leak the balance of channels by the feerates on the channel, this totally leaks the balance of channels. I don't think this is true -- you ideally want to adjust fees not to maintain a balanced channel (50% on each side), but a balanced *flow* (1:1 incoming/outgoing payment volume) -- it doesn't really matter if you get the balanced flow that results in an average of a 50:50, 80:20 or 20:80 ratio of channel balances (at least, it doesn't as long as your channel capacity is 10 or 100 times the payment size, and your variance is correspondingly low). Further, you have two degrees of freedom when setting fee rates: one is how balanced the flows are, which controls how long your channel can remain useful, but the other is how *much* flow there is -- if halving your fee rate doubles the flow rate in sats/hour, then that will still increase your profit. That also doesn't leak balance information. > ### Inverting The Filter: Feerate Cards > Basically, a feerate card is a mapping between a probability-of-success range and a feerate. > * 00%->25%: -10ppm > * 26%->50%: 1ppm > * 51%->75%: 5ppm > * 76%->100%: 50ppm Feerate cards don't really make sense to me; "probability of success" isn't a real measure the payer can use -- naively, if it were, they could just retry at 1ppm 10 times and get to 95% chances of success. But if they can afford to retry (background rebalancing?), they might as well just try at -10ppm, 1ppm, 5ppm, 10ppm (or perhaps with a binary search?), and see if they're lucky; but if they want a 1s response time, and can't afford retries, what good is even a 75% chance of success if that's the individual success rate on each hop of their five hop path? And if you're not just going by odds of having to retry, then you need to get some current information about the channel to plug into the formula; but if you're getting *current* information, why not let that information be the feerate directly? > 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. If your current fee rate is F (ppm), and your current volume (flow) is V (sats forwarded per hour), then your profit is FV. If dropping your fee rate by dF (<0) results in an increase of V by dV (>0), then you want: (F+dF)(V+dV) > FV FV + VdF + FdV + dFdV > FV FdV > -VdF dV/dF < -V/F (flip the inequality because dF is negative) (dV/V)/(dF/F) < -1 (fee-elasticity of volume is in the elastic region) (<-1 == elastic == flow changes more than the fee does == drop the fee rate; >-1 == ineleastic == flow changes less than the fee does == raise the fee rate; =-1 == unit elastic == you've found a locally optimal fee rate) You could optimise base fee in the same way, if you set F to be sats/tx and V to be txs/hour, but then you're trying to optimise two variables on a 2 dimensional plane, which is harder. So probably better to do zero base fees and just set it to 0 and ignore it, or use your actual computation costs -- perhaps about 20msat if you're paying $100USD/month for your lightning node, a channel update takes 10ms, each forwarded HTLC accounts for 4 updates, 2 on the incoming channel, 2 on the outgoing, with no batching, and only 40% of payments are successful, at $20k/BTC. It's likely more important to have balanced flows than maximally profitable ones though, as that's what allows you to keep your channel open. That's probably pretty hard to optimise, since a changed fee on one channel will affect the volume on ther channels as well. Relatedly: > I want to propose that all published nodes support some kind of > onchain/offchain swap capability. If you're running a forwarding node, and collecting fees for forwarding, considered in net your channels won't be balanced: the fees you collect are all coming in, and there's nothing to compensate for that. Having some way to send those fees "out" is necessary to keep your channels balanced and avoid the need to have to close them. Having a swap capability like this is perhaps a relatively easy way to be able to (automatically) fix imbalances caused by collecting fees, and thus preserve your older channels. Cheers, aj