Published on: 2019-01-20T02:25:34+00:00
Anton has been addressed regarding the use of Bitrefill account funds for incoming channels. The writer explains that while an incoming channel typically refers to a channel where the funds are owned by the counterparty, allowing the user to receive money through it, if the user owns the funds, they cannot use their Bitrefill account funds to obtain an incoming channel. Instead, the writer suggests that the funds could be used to pay for incoming liquidity, which is now part of the liquidity provider proposal.Anton's proposal for using the LN node key as a stable user identifier for payer/payee interactions on the Lightning Network has received a response from ZmnSCPxj, a contributor to the LN development. ZmnSCPxj discusses four use cases that should be implemented within BOLT rather than as separate HTTP requests. The first use case involves the incoming payment channel request, which would allow liquidity providers to sell a service of providing incoming liquidity to nodes in exchange for a fee.The second use case addresses the issue of withdrawing funds from a service and the associated fees on Lightning, particularly for custodial services. ZmnSCPxj suggests adapting Rendezvous routing to custodial service withdrawals as a better solution. This would prevent the revealing of the user's public node to the service, thus avoiding personally-identifiable information concerns.The third use case focuses on linkable payments. ZmnSCPxj mentions that payments sent by the payer and interpreted by the payee will soon have type-length-value (tlv). Adding a user-linking-key to this key-value map would be straightforward. Lastly, the fourth use case involves logging in with a Bitcoin wallet, which could also incorporate a user-challenge using the tlv.ZmnSCPxj concludes by emphasizing that these use cases should be implemented within BOLT "soon" rather than as separate HTTP requests. He suggests that Anton reach out to cdecker and CJP to discuss adapting Rendezvous routing to custodial service withdrawals.In an effort to address the lack of user-friendliness on the Lightning Network, a standard is being proposed for payer/payee interactions that builds upon Lightning invoices. This spec defines four use cases, including incoming payment channel requests, withdrawing funds from a service, linkable payments, and logging in with a Bitcoin wallet. Two of these use cases, linkable payments, and log in with a Bitcoin wallet, require a stable user identifier. The proposed solution involves deriving a unique `LinkingKey` for each `(user, service)` pair, preventing actions from being linked across different services. The author requests a review of the cryptographic protocol outlined in the spec, which can be found at https://github.com/btcontract/lnurl-rfc/blob/master/spec.md.
Updated on: 2023-07-31T21:23:44.283274+00:00