Create 2022-08-17.md

2022-08-17.md

@@ -0,0 +1,176 @@
+**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
+Zero Conf - 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. 
+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**
+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** - 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