Corné Plooy [ARCHIVE] on Nostr: 📅 Original date posted:2018-03-15 📝 Original message: Hi Andy, 1. Don't confuse ...
đź“… Original date posted:2018-03-15
đź“ť Original message:
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 at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
đź“ť Original message:
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 at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>