Andy Schroder [ARCHIVE] on Nostr: 📅 Original date posted:2018-03-10 📝 Original message: Hello Corné, I'm glad to ...
đź“… 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>;
đź“ť 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>;