2022/08/31 11:00 UTC - LSP Spec Meeting
Video of call: https://drive.google.com/file/d/1IKqyh7Ksizmt4J4qOnMfF_PnkmrIBEXs/view?usp=sharing
Attendees:
John Carvalho / Reza Bandegi / Sevi Buhler / Elias Rohrer / Christian Decker / Corey Philipps / Pavel Nikolov / Lucas Ferreira / Nick Slaney / Ivan Razsl (LN+) / Aljaz Ceru
Notes by Pav Nikolov:
John Carvalho - recap of last session - marketplace APIs. What is the minimum data a consumer / buyer would need from node in order to make a decision. Bid / Ask context may not be ideal for everything - as every LSP has slightly different ways it operates & prices things.
Christian Decker - hard to define what we want to share in terms of info for Liquidity ads, we need to go from the public info we have so far John - some context of your reputation + terms can be provided. It was brought up latency / quality which wasn't very useful CD - we are trying to optimize for minimal risk and maximum utility that we get from a channel partner, reputation is one way of doing that - Liqudiity ads has a way to punish misbehaving peer and close a channel - quality and utility we get from opening a channel with a peer is something we can measure, risk isn't and reputation is difficult to put into numbers - feels like a deep rabbit whole.
John - define a scheme to weight data, share attestations for different nodes and people share this web of trust and choose a perspective of how you want to weigh that - that is quite elaborateive and can become quite infinite and comlicated. Pool used Bass score, as soon as you choose multiple peers to buy channel from, this needs to be expressed digitially you need to collect the data CD - its hard to define reputations, not that it's not possible or practical. We can guess and do an interative approach of what makes sense and what doesn't Sevi - may not be good to standardise reputation in a group, as these will change overtime. Latency is a big question, with Thor nodes, slow nodes we have in the network, in the future as soon as we have trampoline routing, trampoline operators can optimise nodes for higher speed, it will not be such a higher issue - we should focus on obvious things - routing fees, but not go too deep into the rabbit whole of what everything else will be Ivan - once scary thing about reputation is, peeps buying liquidity will opt for the first 5 high scoring nodes, may not understand what the score means, whcih can create centralisation effect, due to ignorance from buyers John - expressing the part of reputation is the problem. you cant remove reputation from decision process. The issue here is there are different kinds of users (Amboss vs Breez vs Pool vs Liquidity Ads for example). Ivan - the solution can be to provide many different ways to sort the data - price, reputation etc and that will allow different nodes to rise to the top with different metrics.
Aljaz - reputation should be secondary CD - push back against reputation if its not publicly described
JC - what is a minimum data set that we can agree on, that is self attesting for nodes to provide (agree reputation can be secondary) - have a look at what was submitted yesterday and see if it makes sense. Then we can give a scoring system and that serves an abstracted way of scoring nodes.
Reza - uptime, is important, If your peer has channel counts, see if they close and open a lot of channels (volume) have to put some thought into that. You can go to these explorers to make a decision (Amboss, 1ML etc)
Aljaz - you don't have this data initially.
JC - you can measure uptime, it won't be 100% reliable or true
CD - there is a point from taking data which is publicly available - can extract it from channel notes from gossip network. It is good idea to have aggregators of that info but always be possible to reconstruct that so there is no power plays for aggregators
differentiate what we can witness ourselves and choose an aggregator and what they exclusively have access to
Sevi - for scale this won't be a solution.
Aljaz - if we don't put reputation by definition we are not prescribing what info can be used to make decisions,
CD - we don't know how to quantiy utility, risk and evaluate with each other. Reputation systems are a deep problem to solve, beyond the scope of this group.
Sevi - I like Aljaz propositoin - we need to remove reputation and latency. It's kind of liquidity ads and pool - minimal set we discussed last week, this is still a draft for this week.
Aljaz - Blockrate is sats per block - the naming is not ideal, comparing naming of parameters from Pool and LAds - not a huge fan of this either, but its basically a timeframe (selling X for 30 days) similar to duration.
Reza - except Blockrate, we can express this data. as LSP blocktime is uncertain, we don't use it as LSP.
Sevi - the only reason to have blocktime is to lock the liquidity in the channel.
Nick - as long as there is an aspect of time, it's OK. with BTank you will probably have certain amount for duration.
JC - we use a rate for the amount of BTC over time. If you choose 4 or 8 week channel, we don't scale rate over time - we use the lending the FRR rate on Bitfinex. It's pretty low rate, so it works well - we thought it would work well if there is a deep market on LN. We calculate the FRR now (1% per day x the number of days + amount of BTC).
another parameter - you can config the amount of BTC on your side of the channel (incoming and outgoing) this increases the fee. The liquidity from us is what we charge the rate on
tier rate for routing fees - it seems people prefer to have upfront fee and have 0 routing fees, that may turn out to be the way to go - we've designed things by tier (from higher to low % depending on volume)
Closing terms - current design would be if over time, the amount of routing fees earned over the period of the channel, we'll close the channel or offer a renewal rate. If you have earned more on routing fees rather than lending the funds to someone else, we will keep the channel
Top up request can be made as well - we'll present an invoice and pay us from any node or on-chain. This is separate from "keep alive" the channel.
Ivan - we may want to specify how much % of liquidity is on each side, some liquidity buyers would want channels to be completely empty - or a specific amount
JC / Aljaz - auto-balancing - subscribe to auto top ups - automatically approving a fee to always stay at 50% everytime it falls to 10%. Base rate is a static fee. Will add some description to each field - you'll also need a lending rate as a fee.
Nick - blockrate can be the fee rate, we need to clarify that this is over a period of time. Good idea for us to set a formula - fee rate over time.
Reza - another thing to think about is - channel closing enforcement / punishment mechanism - in Magma if you close a channel prematurely it affects your score - similar dynamic on Pool and Liquidity Ads. Something that people may want to know when buying a channel.
Aljaz to update the proposition after Riga
Next time we can review the update from the spec - how to reflect it to the public and implement it. Get some feedback from Liquidity Ads and Pool and see if they want to implement it.