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 <zmnsc...@protonmail.com>
Отправлено: 19 января 2019 г. 5:04
Кому: Anton Kumaigorodskiy
Копия: lightning-dev@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 
<anton.kumaigorods...@outlook.com> 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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Reply via email to