2022/08/17 11:00 UTC - LSP Spec Meeting
Video of call: https://drive.google.com/file/d/1k8BR_a4kuVseyNglf7-SoJa8dwhniY-F/view
Attendees:
John C / Reza B / Ryan Gentry / Lucas Ferreira / Jesse (Amboss) / Daniel Stadilus / Corey Phillips / Vivek K / Yaacov / Rene Pickhardt / Aljaz Ceru / Pav N
Notes by Pav Nikolov:
LSPS.1 has been posted
- please provide feedback. link to new zero-conf docs in case curious https://github.com/lightningnetwork/lnd/blob/master/docs/zero_conf_channels.md
- currently spec does not have anything about that, the spec is fluid, as we go forward we can add something to 0-conf channels to it. Open for questions in TG
- JIT stuff - Yaacov included a PR (few hours ago) - Reza to check. RPC and Rust will be added in a new PR - Reza merged both the PRs thinking we can add as we move forward - most of the people seem to be in agreement, hence the merge.
Next Topic - Marketplace API
Jesse curious to understand what the vision of the problem is we are trying to solve.
John as an LSP - we should cross post liquidity on Magma / Amboss
- how can we make it so to infertace with the platform to post and pull information / coordinate transactionally
- LN+
- on a lightning profile page, one of the things we can do is, give people a widget and buy a channel from that node - API can cover the use case. There needs to be a way as an LSP to interact with a website Breez - their vision for their wallet is to support LSPs (not sure how the UX is), we are hardwiring that to our wallet, we want the user to choose which LSP they use
- pull data from multiple LSP's, this may involve more info in the API (what your terms are for the initial opening fee, routing fees, routing tiers etc ) - how can we give market participants to weight this data (perhaps a bigger conversation to be had)
Daniel - on 1 end of the spectrum, we are collecting info which for certain part of the market works, balance of trust / identity performance. On the other side, we have markets are bonded, performance is certified and checked - entities may want one of those properties in a certain amount - may have some trade offs. maybe the way to frame how the market is evolving is, inbound liquidity is offering:
- Classified-ads experience (solicit across a myriad/open set of sellers with low trust in identity but large assumptions about channel-open performance) e.g. Magma
- Boutique (a single commercial entity that pairs cross-user needs of sending outbound and receiving inbound, dependent on balance of flows) e.g. "effortless inbound" Voltage
- SuperMarket (solicit across many sources of inbound with low identity trust and certified potential for channel-open performance) e.g. Pool
Jesse Automation possibilities - Amboss can have that automated. there are some fundamental differences.
John - all of them are reputation based systems. Pool still uses some reputation system. Commonality would be the promise details - keep channel open for such duration for such fee. Pool certifies - liquidity offered in the market exists and can be opened. There are quality criterias that they grade people on and there is actual enforcement. Some criterias Terms Scoring Enforcement Reputation Quality and liquidity certifications are being handled.
René Pickhardt I think there is a difference in pricing for last mile end users of offered liquidity and professionel liquidity between routing nodes. I guess the API should reflect that?
John in the spec, these things behave as primitives, there shouldn't be any commonalities should have different specs -
Daniel Spec on how each marketplace judges the quality of a node.
John If I want to assemble a marketplace and display it to my users - I should be able to do it in any way as I please (pull and assemble the data)
Jesse maybe this is not ideal for spec.
Daniel not super relevant - if an entity says they want to check something, LSP sell liquidity user to choose where to get liquidity / matched
John As an LSP if I want to participate in the 3 marketplaces (liquidity ads, magma, pool) if the marketplaces support the spec, and I as a user can move to any marketplace
Aljaz Ceru we are talking about several different things here, we should separate market data (asks and bids) and this should be the first thing that we discuss - what is the minimum data set that every orderbook should include and how the api for retrieving that should look Separate market data (asks and bids) - we should separate these into topics as a base level information. Gathering order books from all other exchanges - to have an idea of what is available out there. Create data collection into a super order book. +1 Daniel
Ryan have a standard interface to post orders / orderbook to post on these marketplaces all marketplace's have different terms, requirements to post my liquidity
John Bids / Asks and thinking of these as exchanges - is a good framing. How do I request an orderbook from a marketplace and compile them
Daniel with Pool you can't do costless spoofing. if you need trust minimization bonded liquidity (so you know the offers that exist on the book can be enforced) and you don't want to go to classified ad - there are trade offs, the problem with classified ad market - its costless to spoof, and the reason why people pay premium to pool is because they can source liquidity quickly.
John I don't like the server isn't open sourced in terms of interoperability it's not ideal
Daniel if you don't do trust minimization around order execution / submission, the other option is custodial. We have a difference of opinion on what a spec handles
Ryan Gentry here are the parameters for a Pool ask: https://docs.lightning.engineering/lightning-network-tools/pool/orders Ask Amount: [sats] Ask Duration: [blocks] Total Premium (yield from taker): [sats] Rate Fixed: [sats/block] Rate Per Block: [sats] Execution Fee: [sats] Max batch fee rate: [sat/vByte] Max chain fee: [sats]
Jesse we are not opposed to providing it - its a crucial part of our business. In terms of the format, we can spec that, for the most part we are trying things out and see what sticks.
Aljaz Ceru i think the downside of failed order are significantly overplayed vs buying the wrong liquidity (as not all liquidity is created equal). Reputation is far from the only key thing that will be important long term imho
Reza Liquidity ads is interesting because you broadcast your rates, and crawl the order book + make your own order book as a user.
Rene they are basically gossip over gossip protocol - one thing as a customer I'd be interested in - with whom I can connect if I buy liquidity. In which direction am I expected to route / receive payments if people who offer liquidity offer this info.
Daniel Stadulis We're working on balance of flow signaling in Pool we can't prove graph data? I'm confused
Jesse Amboss.Tech ryan +1 Max batch fee?
Ryan Gentry max on-chain fee a seller is willing to pay if an order is matched protects the seller from losing their margin by getting matched when mempool is full and fee rates are high
Jesse Amboss.Tech hmm okay we don't have that
Daniel Stadulis the batch fee also handles coordinating the batch channel open process so everyone in pool gets cost savings to open channels because of the shared inputs
Ryan lets start with what are the key components of: ask bid alignment on what that is first for an LSP group to create asks in these different marketplaces Plugging into Pool - Voltage does this (both LSP will open inbound channels to nodes) they offer additionally to those channels to buy for their users - Voltage has control over You can have a standardized look at what criteria can be agree for asks / bids. From there we can go to.
John As a singular LSP we don't really have asks - we have a rate + quality.
Ryan what a Pool ask looks like - rate x duration = fixed amount of sats. Are you selling open ended channels with no fixed duration.
John We sell directly, operating as a merchant selling things, trusting our reputation and paying upfront + delivering after. Config your bid is what the Blocktank widget does.
Ryan you are willing to fill them depending on the price. When you move to a market place / orderbook format - OTC / RFQ what fits as a classified ads experience - this is where asks / bids are the format for it.
Daniel the rates on pool https://twitter.com/lightningpool there is outdated info on liquidity ad - a way for the market to see if this signal is strong.
Aljaz Ceru Its important who you are buying the liquidity from as oppose to just get the liquidity
Ryan gah, does anybody know the parameters of a given liquidity ad? I can't figure it out from the PR - https://github.com/lightning/bolts/pull/878/files
Daniel client is opened source, server - can be open sourced but the market will fragment liquidity (further fragment it)
John liquidity should be treated relatively, decided by reputation which is inevitable, from P2P design pov - you should have peers equal to other peers if they so choose to, nodes should be able to submit and provide + pull / assemble data for a marketplace https://blog.blockstream.com/setting-up-liquidity-ads-in-c-lightning/
Reza Bandegi https://lnrouter.app/liquidity-ads
Aljaz Ceru lease_fee_base_msat lease_fee_basis funding_weight channel_fee_max_base_msat chanel_fee_max_proportional_thousandths compact_lease
Daniel Stadulis I think reputation certification cost is high and using the trust minimization properties of bitcoin and cryptography will be cheaper long term
Rene reputation + latency (geo location) are also important
Aljaz Ceru yes and no. what we want is to have visibility into what is out there and then decide ourselves
Daniel Stadulis a node isn't necessarily in the same geo location
John proximity will matter (not sure if its solved by a spec) reputation needs to be addressed (not necessarily in this form of work at this early stage) as a service provider this is what you are competing on
Jesse Amboss.Tech I think the area for spec may simply reside in units and calculation methodology
Aljaz Ceru reputation is too opinionated , we should have base set of data we all agree on should be presented on this and then we can build on top of that
John from a bidder pov - beyond what we have included in the spec - what additional things we want to config + data to pull as a bidder to make a decision and ask a provider what should I be ready to provide?
Next Steps? add a parameter if its bonded
may be useful what parameters exist in the current marketplaces and then agree on a minimal set that is useful - https://docs.amboss.space/
Ryan Gentry here's the link to detailed ask/bid information for Pool https://docs.lightning.engineering/lightning-network-tools/pool/orders#detailed-field-breakdown
Jesse Amboss.Tech https://studio.apollographql.com/public/amboss-production/explorer?variant=current Liquidity Ads https://blog.blockstream.com/setting-up-liquidity-ads-in-c-lightning/
too early for specs, lets aggregate parameters first