2022/09/28 11:00 UTC - LSP Spec Meeting
Video of call: NOT RECORDED, SORRY
Attendees:
John Carvalho, Rene Pickhardt, Corey Phillips, Reza, Aljaz Ceru, Christian Decker, Elias Rohrer, Ryan Gentry, Lucas Ferreira, Ivan Razsl
Notes by Pav Nikolov:
Aljaz - I just threw a couple of things together from last meeting - we discussed various policies and how to implement that - threw a few ideas that are suppose to be a conversation started rather than a strong opinion expanded on "defining units" Agree / discuss on how the structure of the policy is to be written - should be machine readable to some extent (albeit not enforce-able) have name / value - machine readable info field - additional text field (not machine readable)
Ivan - looks good, no further questions, other than the comment about how the formula will work out.
Reza - with the policy, if they are optional, would they have no value or left out, 2nd quesiton - list of policies somewhere so names are consistent when people are using them?
Aljaz - I consider this the same as Blips, the policy should be consistent, people can submit new ones of course, but it would be good for those to be unified. They are optional, it provides additional info - re values, don't provide policies you don't care about, people can create their own policies, so no sense to have them there (lets leave them out if you don't have it)
Reza - particular policies can be elaborated, depending on how people use it - i.e. reputation how it links, if we display on some web UX/UI - reputation will be a list of links for example (don't want to get into this rabbit hole again) - overall would it be good to add some version system, so to account for changes +1 on versioning - Ryan Gentry
Aljaz - it would make sense.
John - I agree too. Fee policies, whether or not you support tiers etc, a lot of these would have parameters on how to define them,
Aljaz - it would make sense to specify certain things so we can explain it better to people, otherwise with fee policies, closing policy there's still plenty of different options.
Ryan - This is only for reponse? In terms of reputation, could you request a reputation from a specific provider, or do some negotiation on what provider the buyer and seller want to use, or is it up to the seller?
John - I like the idea of requesting a rating - or submitting a rating is something to spec and would be useful.
Ryan - part of the order, this is the request message - you as a seller specify the policies, the data is generated by the seller (ie what I am offering to the market) - so the reputation is something that needs to be provided according to this external provider
John - or maybe do it both ways - here is what I am rating you, you can rate me?
Reza - the good thing about how its setup in the policy, if we have different systems, we can define them differently and later on we expand on them
John - if we make a spec of the reputation, what systems you use and give me all records that you have - I can decide if I rate you, and if I have a system I can add you to the list of ratings - probably the simples primitive (system and list)
Aljaz - that makes sense, pub key is unique identifier - I am present on this ranking / reputation system and can expand to 2 policies reputation list - list all services / where you are present - provide your info + internal ranking system
John - I think it can be one, I'd just change the list name = name policy value = what system has been used, either ID so I can see more about the ranking system data / info = rankings , ratings you provided about other people or collected about people supply data with list of proofs, but in the end is a list of rankings (list of rankings) that's how I'd do it, feel free to chime in - will put an example / comment to make it more clear
Ivan - you would be able to request the reputation from a provider for a specific pub key - is that a need? I am working on providing an API for reputation and wasn't thinking of this use case,
John - I think it's covered by the design I am proposing - ask a node what reputation system you are using + what ratings you have - as long as the system you use have some proofing (ecnrypted, using a key etc) - anyone can serve ratings to anybody with integrity It may not be my node ID, but ultimate primitive is what system you are using what are your ratings
Ryan - I know the terminal scores, the way the values are scaled (max is 100m) if you are above 10m you are on the list, this is getting beyond the scope of this discussion, it would be interesting to think how to normalise the scoring systems - Slashtags are 0-10, LN+ 0-100 coming up with some kind of normalisation so they compare 1-to-1
John - mapping schemas, community is small so people will converge, but as long as the data and you know how to parse the data, use whatever method you want to slice the data As long as you have the data and its raw, you can do the rest. We don't need more than 2 values - one points to someone the spec for the reputation system and another one points to where to get your db of rankings / ratings.
Aljaz - we should figure out how to express the rate fee formula -
John - using all variables from the spec - time, size fee, duration etc Will submit something in GitHub so its more digestible so we can start working on policy (closing policy etc)
Aljaz - specify unit upfront , doesn't matter if its time or block, I want to round this down, already proposed a duration unit.
John - can we support / enforce both? I may need to express it in blocks as this is how it may express it in blocks. I can put a time limit regardless of the blocks, so maybe we give the people the ability to express both
Ryan - if the duration in this part of the spec is blocks and left up to the client to convert to time
John - that works until the blocks are empty, flexibility is gone if we define it in blocks. If we are using an enforced DLC contract, user may have no chance - we not use both instead.
Ryan - I am fine with the flexibility
John - can we have 2 fields, I pick what I care about, or pick both if they are too - min duration clock / block?!
Reza - making it separate makes sense, we could say we can use both, which was first and specify in the duration policy, whatever hits first is going to be enforced.
John - closing policy can be something very simple - min block = 0 = close or something like that (not the actual expression obv).
if we use a rate and decimals, how do we limit the amount of —- if we use ppm - is it millions satoshis or msats - is that confusing? Do we support both or is it the same problem we just discuss and peeps parse it
Ryan - because everything in the BOLTZ is in ppm terms, bips is much better, aligning with the spec and keeping it with ppm and converting it on the client side - so it's actual sats
John / Aljaz - I agree
ppm is more expressive and can be converted to bips, can have a conversation over a beer sometime 😄
we can specify it in the spec so people can read it and understand it
What would be our strategy to get this spec into marketplaces Ryan - the thing that conflicts the most is channel request / channel response model - if a node has an order on the Pool order book, how they could communicate that to someone else, channel request, they respond back - this is very p2p, Pool works in a different way (I have an order in this venue that you can buy) I can sell you a channel, not from myself directly but from the Pool order book and guarantee you this minimum threshold - I am not opposed to having nodes on Pool - but how would the node route the order to the Pool order book LSP group - how can we always form the data in the same way when selling liquidity - Pool already exist but it speaks
could the channel request method be a method for config the asks, than the purchase ?
Ryan - LN router (composed a book from that) and Liquidity Ads (p2p model) have converged - the min / max size conflicts a bit with the order. Pool works you put max size (1 btc to order) and willing to sell to tranches as small as 100k sats. If an LSP has a max size at a given rate and is open to responding for that, Amboss can suck that info to their order book. Pool would suck that in in a bit of different.
John - what if you made sure that the bids in Pool had the data that LSP needed, then LSP would run bids as requests, if LSP wants to participate in Pool, it will parse the bids and match with the policies - order generation scheme - treats all bids as requests, parses them and fulfills them when they can
Ryan - the model that works well here - LSP has an account funded in Pool (voltage flow is good example), a user shows up and does a channel request from voltage, puts a field - OK with buying from Pool not from you, Voltage goes to market place and passes the request and gets it filled, opens channel from actual seller, to the buyer who requested it.
Flow / Voltage is channel broker - they receive request, find someone to fill it and facilitate channel open there. Specify a white list of pub keys to buy from - we do have letting users opt in to make their orders public, everything will be private by default, but people can see that you have an order on the book and will make the transition easier.
Aljaz- this model may work - this spec is mix of Pool and Liquidity Ads
Ryan - this model specifies the pub key who do I want to buy the channel from, still can work with marketplace model, it would be interesting to have a model where - I don't care about pubkey, I just want to buy from this venue as long as they meet a certain threshold,
John - I need the reputation to match that they are well connected (we are not at that level of sophistication
Aljaz - this is my motivation, to lead this effort, we want to build this and generalizing how the orders look will simplify the integrations so we can pull the data
Ryan - I don't think that there is anything in here that blocks nodes who want to interact with Pool to interact with this format, we have enough tools to do translation between the two, we have all the tools to support that and nothings is preventing integration
Pool / Magma do support local balances (double check on Magma) LN+ - we do have a concept for dual funded channels that we use Amboss so its techncially 50/50 on both sides
Next meeting overlapping with BTC Amsterdam - we will push it with another week