Skip to content

Latest commit

 

History

History
85 lines (50 loc) · 6.17 KB

2022-10-19.md

File metadata and controls

85 lines (50 loc) · 6.17 KB

2022/10/19 11:00 UTC - LSP Spec Meeting

Video of call: https://drive.google.com/file/d/1aW5kCLmlu9zf8X-6SIK6SO7tZAdX7bO7/view?usp=sharing

Attendees:

John Carvalho, Sevi, Ryan Gentry, Aljaz Ceru, Elias Rohrer

Notes by Pav Nikolov:

Aljaz - put together a summarised version of what is in the issue - all is covered except how we want to enforce policies - mix of both, can be found under "Existing policies" what is left is agree on the structure (name, value, info)

Sevi - I went through it, only thing that came up not sure how any HTLC size - usually it will be variable depending on the flow, not sure how this fits in here (need to ask Rene myself) maybe we need a policy for node locations - LSP have nodes around the world, they want preferably users to connect to the closes to them - maybe we have a policy to announce location of node

Aljaz - I imagine that as part of reputation system, location might make sense - generally you want to buy from a specific location,

John - location only matters if you are at max latency performance, if you are closer doesn't mean its faster

Aljaz - I don't agree - you may not want to do business with a certain jurisdiction,

John - if you are enforcing a black list, you have to your jurisdictional DD to prevent doing business with them

Sevi - you can always derive info from node's address, it requires IP location table, we can make it easier ...

Aljaz - idea of policy is that is extandanble - adding location, isn't changing anything and is achievable

John - does it mean we should add terms of use (legal), privacy - may not be a bad idea

Sevi - maybe 1 website, that you can put (channel info contact) - general website

John - legal asked how do people contact you regarding support - if people buy channels they need to have a way to find you / contact you

Aljaz - info / contact would be a good idea

Ryan - how bullish are you on push/support idea - user wants a channel that is immediately spendable on LN vs what Breez

John - we've been trying to get 0conf channels for years

Ryan - 0conf send addition to Pool, instead of on-chain funds opening a channel directly, allows you to have a channel opened to you that is spendable - instead of opening a channel with user coins -

John - we never open a channel with user's coins, it's always coming from BT - cost of your channel is a formula of your local balance + rental fee for incoming balance Push support will be obsolete when you have dual funding channels which is what we are creating Do-able spending situation is different when you are funding vs the user is funding (user pays you with 0conf on chain, you can dictate to make their channel instantly expendable and whether or not you will forward payments to them) vs dual funded - would you forward right away from their 0 conf thing? the more permisionless you get the LSP connection the more dicey it gets

Aljaz - there are slightly different use cases, supporting push is a bit more different in that it caters for different audience.

John - we will probably go towards as deterministic as possible outcome

Ryan - 1 specific use case - user btc on bitfinex, and isntead of spending on btf node, would prefer to withdraw to a self custodial wallet in a manner that is immediately spendable on LN - maybe the entity opening the channel and pushing the balance is not just accepting 0conf but also is the custodian If there is demand from user to hold their own keys - easiest thing is to leave the coins on the exchange (which we don't want)

John - the situation is dedicated, this is possible because there is a custodian starting it, but the UX flow for the wallet - I need a wallet able to accept any payment, which means you need LSP, JIT channels etc

John - VASP / FATF - we are in waiting mode, Elizabeth is in touch with people, nobody has done this before, there is no precedent, as long as you are non-custodial you are passing messages, if you are non-custodial you are message passing, nothing active, we are in "wait and see" mode.

John - the wording of this is broad on purpose, and it can be easily encompasses every routing node, LSP, Pool, Loop etc etc Taro Edge nodes - we need to try and figure out how to portray the narrative and highlight LN in a good light

Aljaz - push support is optional, BT we are reducing channel size to $1000, since we are launching in Beta, so we don't qualify as a VASP

Ryan - being non custodial as possible + keeping small amounts to be on the safe side, from what I've heard from people close to policy making is - document, document, document in the face of uncertainty - this is how we interpreted the decision at the time being etc etc

John - I don't even think they added LN in this on purpose, it was more by accident Exchanges monitor both on and off ramps - withdrawing on LN is not a way to circumvent AML

John - we'd have a consortium of LN people on calls to describe LN, LSPs to normies and policy makers and how each service works and are unintentionally wrapped in

and we can prepare research paper and content that our lawyers can use to contact policy makers and regulators we are looking for exception for VASPS for our LSP - we can be working on this together.

John - back to topic - add location, more policy links and finalize the scheme for policies and including of reputation. Lets get this first version and at least one LSP to support the request spec and at least one marketplace to support the spec, so we have some feedback. Let those specs bake for a while and then we get to work on reputation. I will make a repo for you Aljaz instead of working inside of comments -

Ryan - I have a question - a lot of the spec people were at Conf - are you familiar with async payments proposal? It seems that it has a broad support of LSPs

John - we are all interested in async stuff, for LN just don't have the time for this - once that is ready, once that is working for LDK we will add it. As far as the LSP we haven't touched anything, we will start looking at it after the launch. Add CLN, LDK. Peerswap maybe, 0 conf for sure, async payments etc

Ryan - once the async payments spec is finalized, we can have a nice wrapper around it. we will start on sub Bolt 12 on this version later this year