Hi Andy,
1. Don't confuse TOR onion routing (used for anonymous/pseudonymous communication) with Lightning onion routing (used for anonymous payments). TOR's design is outside the scope of the discussion; as far as I can see, TOR is only relevant because it exists, it works(*) and it is useful to us. The "partial onion route" is about Lightning's onion routing. You could consider the start of the partial route as an "introduction point"; it is selected by the payee(**). I'm not sure if it is exactly equivalent to TOR's introduction points though. 2. Good thinking. I guess that, since either payer *or* payee will decide on the amount, there is no use case for omitting the amount in an invoice in BOLT 12; unlike BOLT 11, it should not be optional here. So that's not a problem for the partial onion route. Unknown capacity is an issue, and I guess it's worse than if the payer is completely free to choose a route, because the payer is no longer completely free to choose alternative routes. Giving a batch of alternative routes is one concept (TBD: can they have the same payment hash?); giving new alternatives interactively is another option. I think using the same "introduction point" for all routes is best for privacy: otherwise the payer could determine the neighborhood of the payee. 3. True. Right now I'm thinking in the opposite direction: simplifying BOLT 12 by removing the possibility of refunds. We can always add it back later (with a proper set of features for all kinds of refunds) as an optional feature. 4. This depends on the use case. The URL contains an optional invoice ID. A payee can request a payment for a specific, single transaction (for a single instance of delivery of goods/services) by handing over an URL, including an invoice ID, to a single payer. This provides similar functionality as BOLT 11, except that you now have a well-defined channel for transmitting larger invoice descriptions and for using partial onion routes. A payee can also hand over an URL without invoice ID; this can be used and re-used by one or more payers, whenever they want to perform payments to this payee. Thanks for the questions; I think I can improve my proposal based on your feedback. What should I do with BOLT 12? Have it pulled in lightningnetwork/lightning-rfc; maybe in a separate branch? Or first work it out in more detail? How does lightningnetwork/lightning-rfc distinguish between drafts, finished agreed-on specs and things we decided we don't want? Is there even a consensus forming mechanism? CJP (*) to some degree; there are limits to the privacy provided by TOR. (**) when extending the current BOLT 12 draft a bit, it might also optionally be selected by the payer. Op 10-03-18 om 06:16 schreef Andy Schroder: > 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@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
