2022/09/14 11:00 UTC - LSP Spec Meeting
Video of call: https://drive.google.com/file/d/1Zo9zvDQ8Son-rPaAgP_SuO1LBoQc8e97/view?usp=sharing
Attendees:
John Carvalho, Nick Slaney, Rene Pickhardt, Corey Phillips, Reza, Aljaz, Christian Decker, Elias Rohrer, Ryan Gentry, Lucas Ferreira
Notes by Pav Nikolov:
John - last week we further discussed LSP market spec -
Aljaz - expanded on the description side, identified quite a few questions to address: size - 2 ways to approach -1 more ordebook like (10m sat for X) some market places this is the amount I am willing to sell (min to max order size) - this is the first thing to decide because it impacts other parameters
John - why not have both? Have an inventory and min/max and set them to the same number
Aljaz - this would have an implication on the rate - fixed cost and then you have the selling size (what Amboss are doing) or duration. If we have all of the options it starts complicated.
Ryan - Pool does min / max but you can bump it up - charged sats / block.
Aljaz - that makes sense but it has implications for on-chain fees /
John - express the formula used for the fee - the way this nodes calculates formula is min rate x XYZ divided by ZYX and this way we can see how people formulate the mounts, marketplace can still pull that data
Ryan - are all of these assuming upfront payment in full?
John - the only spec we have created is the channel request. As far as fee upfront, we should allow people to charge only upfront fees and 0 routing fees, or require the balance to be on the buyer side.
Ryan - reason why we did pool / block, instead of packaging payment on LN, its just 1 payment during the lease, programmatically you can pay a certain amount of Satoshis per block - far future looking stuff, it will be a channel within a channel. New commitment transaction that is only paying out when a new block occurs. I am only saying this to offer context for the per block number.
John - Even if does exist, it will be trusted not enforced.
Aljaz - we are talking about minimal specs. We can't expect that everyone will have enforce that even if Pool does. It touches the discussion on time/blocks.
John - in the event that difficulty adjusts a lot, per block gets weird, per block is something you can improve. If we can have both as a parameter, we use both, difficulty adjusts a lot it becomes weird.
Aljaz - for now we can leave both in, as its not that problematic - specify block or time (for minimum duration) We won't come with a list of all the policies, hence the design of the list, so policies can be extended - a list of parameters explain things.
Closing policy -
John - having a generic area to express text is appropriate. Having a specific policy will be an emerging occurrence -
Aljaz - we should have a programmatic way of describing it and a list of fields
Nick - if we only do fixed amounts - showing a fee. If we allow people to request different sizes - we need to describe how that is calculated. It makes sense to keep this field (min / max) and then on rate fee - anything else besides size of channel or duration?
John - I do think there will be both, when it's a range you provide a formula (and giving it to them is easier) On-chain fees as base fees, not sure if you need anything else to express, LSP should be aware that a base fee should be included , 0 routing fees.
Nick - for onchain fees, LSP can dynamically update. on the fee rate - it can be implied formula like min-duration and that adds time element to fee rate and not have 2 formulas.
John - formula always can be inferred, the other way is to have tiers.
Nick - you can do separate min/max with multiple offers that affect the tiering
John - now we are mixing things - Blocktank does include tiers into the fee we communicate the tiers upfront. Routing never have impact on the fee. Tiering doesn't need to be a concept in the formula but needs to be communicated
Aljaz - still it works in terms of expressing not to charge more than x, that (tiers)
Closing policy and Routing Policy
Rene / Aljaz - max HTLC size - we can't enforce it for the duration (gentlemen agreement) its more about promise - max HTLC currently and max HTLC size
Aljaz - doesn't have to be a specific field its part of the closing policy or a 3rd policy
HTLC policies to be added Max amount and Max HTLC - you are not going to be very tolerable and won't drain the same amount
Rene - you can do pretty good flow control with HTLC size, out of scope to discuss so far
Outbound capacity we didn't discuss how to fit this in or if its a base - this is part of the formula, for example our wallet will be used with our LSP - we will have automatic minimum balance
side topic - discussion to make that atomic - if we are doing as a dual funded channel so we get our fee - we found that people who don't deal with Lightning, we just call them local / remote - it also gets confusing. Spending and receiving balances (this is more user friendly and less spec friendly)
Ryan - this is the channel request it makes sense to state the spec from the pov from the channel opener (person responding the request) - I am a node on the channel > LSP > channel request > what's the price to open a channel from me? We try to orient everything from buyer / seller pov.
Push amount - seller will push sats to the buyer (only 1 entity can push)
Nick - sounds like this inbound liquidity request should be added as part of the spec. Note's field at the end for reputation
min/max size -
fee rate will be channel size -
factor by time -
Borrowing TLV - this is pre-specified - can be borrowed to solve the problem? You don't need to specify the size, but the format.
Nick - we are trying to specify upfront and there a new ways to deal with things / routing fees etc, fee rate carts, it seems like an endless thing, if we try and overspecify now
Aljaz - we can leave it open ended and update it, but it doesnt hurt if we have a category here. I will throw a proposal and sort it out in the comments
Aljaz to specify these
there should be a set of data that can be read by a machine and automated
there should be a set of data that the user can read
lets spec a way to express policies as oppose to spec ALL the existing policies. It's continuation of the work - we are just discussing things.
Reputation
parameters for reputation - ratings, request a list of all the ratings you've created (Node ID's with a score) Give people to express which system they use, request all the ratings you created and hope that peeps converge on 1 or 2 systems.
parameter for the system or model - ID, or URL how we specify what that is - how are you creating the weighting