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 

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.


Lightning-dev mailing list

Reply via email to