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