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 > Lightningfirstname.lastname@example.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev _______________________________________________ Lightning-dev mailing list Lightningemail@example.com https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev