rich1.0npub1r375vdaydp5nnnytff6ee2kwzxak8whmwkmnkm6h67agr7dadfkqxn6ccqhttps://nostr.ae/npub1r375vdaydp5nnnytff6ee2kwzxak8whmwkmnkm6h67agr7dadfkqxn6ccqnjumphttps://nostr.ae📅 Original date posted:2018-03-10 📝 Original message: Hello Corné, I'm glad to see that someone getting this kind of idea started. I'm still new to some of these topics, but I have a few comments. Hopefully I'm not wasting your time if they are too rudimentary! 1. You mention that the payee gives a URL where the payer can then connect to to request invoices. You mention that this can be a tor hidden service if the payee needs to remain private. You also suggest that the payee can remain private by "payee can send an invoice to payer which has a partial onion route as destination instead of a node ID". I was reading about tor hidden services (https://www.torproject.org/docs/onion-services.html.en), and they require an introduction point, and a rendezvous point. Do we not need this two step process for the payment route, because we already have communication initiated over the anonymous communication channel, and the beginning of the partial onion route is not publicly available information, and can change with every invoice? 2. What happens if the capacity of the partial onion route is no longer sufficient when the payer is ready to pay? Is there a way to provide a few routes just in case? Or, in the case where no amount is specified, how is the partial onion route possible if we don't even know how much capacity may be needed? 3. You say the refund should invalidate the proof of payment of the initial transaction. What about partial refunds? I think there are a lot of applications where there would be a partial refund. 4. You say "this BOLT specifies a protocol where payee gives a URL to one or more potential payers". How does the payer identify itself to the payee so that the payee knows what goods or services that they want an invoice for? Do they send this after making the connection, or is it part of the URL? Andy Schroder On 03/08/2018 10:19 AM, Corné Plooy via Lightning-dev wrote: > Hi, > > I was thinking of how to use Lightning for various types of payments, > and I think it's currently fine for customer/(web)shop type > interactions, but it seems a bit inconvenient for other use cases, e.g. > salary payments or direct pay-out of cryptocurrency bought on an > exchange. I came up with an idea that addresses some of these issues and > more (e.g. payee anonymity) by having a direct line of communication > between payer and payee instead of BOLT11-style interaction. It's still > a bit half-baked, with many details not worked out yet, but you can read > it here, and see if you like where this is going: > > > https://github.com/bitonic-cjp/lightning-rfc/blob/payment-protocol/12-payment-protocol.md > > > In true permissionless fashion, I have been so bolD to register bolT #12 > for my idea. > > > Please let me know what you think. > > kind regards, > > CJP > > > > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180310/b0f5979c/attachment.html>