Re: [Lightning-dev] A protocol for requesting invoices

2018-03-20 Thread Andy Schroder
Andy Schroder On 03/19/2018 09:59 AM, Corné Plooy wrote: It is a public key hash, yes. But what I refer to is that the payee-determined route section, which starts from an introduction point, protects the payee from being located by the payer, but how did the payer contact the payee in the

Re: [Lightning-dev] A protocol for requesting invoices

2018-03-20 Thread Andy Schroder
Andy Schroder On 03/19/2018 08:06 AM, Corné Plooy wrote: What about enforcing a maximum payment amount that can be refunded? Can this help make the amount not a requirement? This way the payment amount will still be open to the payer, but it will have a constraint. I see no use case anymore

Re: [Lightning-dev] A protocol for requesting invoices

2018-03-20 Thread ZmnSCPxj via Lightning-dev
Good morning Corne, > > I suppose the use-case here is that the payee uses many TOR addresses with > > only one LN node. > > Yes. Use different TOR addresses for things you want to keep separated. > > Any TOR address you advertise for channel connections is so widely > > shared through

Re: [Lightning-dev] A protocol for requesting invoices

2018-03-20 Thread Corné Plooy via Lightning-dev
> I suppose the use-case here is that the payee uses many TOR addresses with > only one LN node. Yes. Use different TOR addresses for things you want to keep separated. Any TOR address you advertise for channel connections is so widely shared through gossiping that you can in practice consider

Re: [Lightning-dev] A protocol for requesting invoices

2018-03-19 Thread Corné Plooy via Lightning-dev
> It is a public key hash, yes. But what I refer to is that the > payee-determined route section, which starts from an introduction point, > protects the payee from being located by the payer, but how did the payer > contact the payee in the first place anyway? If it was by IP or non-.onion

Re: [Lightning-dev] A protocol for requesting invoices

2018-03-16 Thread ZmnSCPxj via Lightning-dev
Good morning Andy, > > > 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. > >

Re: [Lightning-dev] A protocol for requesting invoices

2018-03-15 Thread Andy Schroder
Andy Schroder On 03/15/2018 08:31 PM, ZmnSCPxj wrote: Good morning Corne, 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

Re: [Lightning-dev] A protocol for requesting invoices

2018-03-15 Thread ZmnSCPxj via Lightning-dev
Good morning Corne, > 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. It is almost equivalent I think. > > 2.

Re: [Lightning-dev] A protocol for requesting invoices

2018-03-15 Thread Corné Plooy via Lightning-dev
Hi  ZmnSCPxj, Thanks for the links. I've done a bit of reading, and this seems to be the clearest explanation of what the Web Payments Working Group wants to achieve: https://www.w3.org/TR/webpayments-overview/ But maybe Christian can give better / more up-to-date info. From what I can see,

Re: [Lightning-dev] A protocol for requesting invoices

2018-03-08 Thread ZmnSCPxj via Lightning-dev
Good morning Corne, You mention URLs in your draft. This made me remember about the Web Payments Working Group of W3C, https://www.w3.org/Payments/WG/ , of which Decker, Christian of Blockstream is a member: https://www.w3.org/2000/09/dbwg/details?group=83744=1 My understanding is that