From anton.kumaigorodskiy at outlook.com Sat Jan 19 09:01:04 2019 From: anton.kumaigorodskiy at outlook.com (Anton Kumaigorodskiy) Date: Sat, 19 Jan 2019 09:01:04 +0000 Subject: [Lightning-dev] lnurl to enable payer/payee interactions In-Reply-To: References: , Message-ID: ZmnSCPxj, this proposal deliberately tries to deal with tasks which are outside of BOLT, those are quite mundane compared to core LN issues but a common format for these would still help a lot. > At some point after implementing dual-funded channels we will also support advertising of liquidity providers. Use case 1 just recognizes a fact that custodial services exist, users may want to use their funds there to open channels and introduction of protocol-level liquidity providers is unlikely to end that. As an example: users can get an incoming channel from Bitrefill today by utilizing their Bitrefill account funds which may be Bitcoin or altcoins. Later if more services join this can also be fiat, I guess protocol level liquidity advertizing can not and should not take this into account. > 2. Withdrawing funds from a service. > A significant problem with custodial services and LN is the issue of fees on Lightning > A better solution would be to adapt Rendezvous routing to custodial service withdrawals None of this is directly related to use case 2, respected lnurl does not try to replace an invoice format but merely defines a standard way for payer to deliver an invoice to payee. This is a problem mobile wallet users face regulary when they have to somehow get their withdrawal invoince from a phone to a desktop site form. > 3. Linkable payments > Payments will have tlv soon. Is this about additional fields in an onion? Indeed, having that would improve on proposed scheme as it removes the need for HTTP request ahead of payment. However, user wallet still needs to know what kind of data to include in such a field. In a proposed `linking key` scheme service domain name still has to be somehow communicated to user before payment, so the need for invoice embedded tag remains. ________________________________ ??: ZmnSCPxj ??????????: 19 ?????? 2019 ?. 5:04 ????: Anton Kumaigorodskiy ?????: lightning-dev at lists.linuxfoundation.org ????: Re: [Lightning-dev] lnurl to enable payer/payee interactions Hi Anton, I believe all of these will be implemented at some point "soon" within BOLT rather than as a separate HTTP request. 1. Incoming payment channel request. At some point after implementing dual-funded channels we will also support advertising of liquidity providers. Such liquidity providers will sell a service of providing incoming liquidity to nodes in exchange for a fee. > Suppose user has a balance on a certain service which he wishes to turn into an incoming channel and service supports such functionality. The balance would have to be on the user side, which makes it outgoing capacity, not incoming capacity. This is why the proposal in the future is to have liquidity providers of some sort. 2. Withdrawing funds from a service. A significant problem with custodial services and LN is the issue of fees on Lightning. If the service shoulders the Lightning fee, a user can create two nodes, an internal node and an external node. The internal node only has a single channel, that to the external node (and the internal node refuses incoming channel creation requests except from the external node). The external node charges exorbitant fee. The user then indicates the internal node (which has only one channel) as the destination of the withdrawal, forcing the service to also pay the external node (which is controlled by the same user) the exorbitant fee. If the service charges the Lightning fee to the user balance, then the user has to trust the service does not do things like bias routes towards nodes it secretly controls that charge exorbitant fees (basically the dual of the above attack). Finally, this reveals the public node of the user to the service, which is bad because it is personally-identifiable information and the service has no right to know that node and its location on the network. A better solution would be to adapt Rendezvous routing to custodial service withdrawals (ping cdecker and CJP about this). The service publicly provides its LN node. The user generates an onion-wrapped encrypted route from the service node to its own node. The route indicates an amount that has to be released by the service, which also pays fees along the route aside from providing the final value to the user node. * The service does not know the actual destination node since it receives an onion-wrapped route. * The on Lightning fee is effectively deducted by the service from the balance, which prevents the user attacking the service by using the internal-external node attack above. * The service cannot bias the route towards expensive hop nodes it controls, since the user generates the entire route. Of course, it could also use the same internal-external node attack. 3. Linkable payments Payments will have tlv soon. "tlv" means type-length-value. This is basically a key-value map added to each payment, sent by the payer and interpreted by the payee. It would be trivial to add a user-linking-key to such a key-value map, although it would have to be defined by the BOLT spec. 4. Login with Bitcoin wallet The same tlv above can also add a user-challenge. Regards, ZmnSCPxj Sent with ProtonMail Secure Email. ??????? Original Message ??????? On Friday, January 18, 2019 3:42 AM, Anton Kumaigorodskiy wrote: > LN as it exists today is not too convinient for end users, I believe some kind of standard is needed for various payer/payee interactions which builds on Lightning invoices and a fact that Bitcoin wallets contain keychains which can be creatively repurposed, my attempt to get this ball rolling is https://github.com/btcontract/lnurl-rfc/blob/master/spec.md > > So far this spec defines 4 use cases: > > 1. Incoming payment channel request > 2. Withdrawing funds from a service > 3. Linkable payments > 4. Log in with Bitcoin Wallet > > I'd like to give some rationale in particular for use cases 3. (Linkable payments) and 4. (Log in with Bitcoin Wallet) since those are related and define a cryptographic protocol (I think) so I'd be greatful if someone more skilled than me checks if those has any obvious flaws. > > In both of these cases some kind of stable user identifier is needed, a popular candidate for that would be user's LN node key. But that approach seems flawed because it allows to easily link user actions across different services so what's proposed is to derive a special `LinkingKey` which would be unique for each `(user, service)` pair where `user` is basically wallet seed and `service` is a domain name. > > Anton > > > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: