Andy Schroder [ARCHIVE] on Nostr: š Original date posted:2018-03-16 š Original message: Andy Schroder On ...
š
Original date posted:2018-03-16
š Original message:
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 though.
> It is almost equivalent I think.
I've been thinking, and start of the payment route has properties of
both an introduction point and rendezvous point. The introduction point
is chosen by the TOR hidden service, and in this case, the start point
is chosen by the lightning payee (which is hidden if they are operating
over TOR). The TOR rendezvous point is not known to the public (only the
client and the hidden service), and in this case, the start point of the
payment route is also not known by the public (only the payer and the
payee if they are operating over TOR to communicate).
>
>>
>> 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?);
> Yes. When we retry failing routes, we reuse the payment hash until we succeed to pay, or, give up paying. This is simply the same concept.
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.
>
>> 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.
> I wonder. How does the payer contact the payee in the first place, without having located the neighborhood of the payee? If it is via some TOR hidden service, and the payee considers this enough protection, why cannot the same TOR hidden service be used as the address of the LN node of the payee (LN protocol spec allows this, current implementations not so much)? Freenet or I2P, I suppose?
You're saying that a .onion address is really a public key, so their is
no reason to include both a public key and a host name?
>
>>
>> 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.
I want my refund :-) !
http://andyschroder.com/BitcoinVendingDevices/
Rusty already suggested that a return onion be supplied for refunds, but
I'm not sure if he was talking about a partial onion, or a complete
onion, because that discussion was for the case where the original
payment was sent directly to a non-anonymous payee.
I think in this case though, were a partial onion route is supplied for
the initial payment, the refund payment onion route would have to be a
partial one.
All return onions still have the same problem of capacity though.
>>
>> 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.
> How does the payer derive the payment hash? Or does the payer have to contact the payee again to get a fresh payment hash specifically for the payer?
>
> Regards,
> ZmnSCPxj
>
š Original message:
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 though.
> It is almost equivalent I think.
I've been thinking, and start of the payment route has properties of
both an introduction point and rendezvous point. The introduction point
is chosen by the TOR hidden service, and in this case, the start point
is chosen by the lightning payee (which is hidden if they are operating
over TOR). The TOR rendezvous point is not known to the public (only the
client and the hidden service), and in this case, the start point of the
payment route is also not known by the public (only the payer and the
payee if they are operating over TOR to communicate).
>
>>
>> 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?);
> Yes. When we retry failing routes, we reuse the payment hash until we succeed to pay, or, give up paying. This is simply the same concept.
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.
>
>> 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.
> I wonder. How does the payer contact the payee in the first place, without having located the neighborhood of the payee? If it is via some TOR hidden service, and the payee considers this enough protection, why cannot the same TOR hidden service be used as the address of the LN node of the payee (LN protocol spec allows this, current implementations not so much)? Freenet or I2P, I suppose?
You're saying that a .onion address is really a public key, so their is
no reason to include both a public key and a host name?
>
>>
>> 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.
I want my refund :-) !
http://andyschroder.com/BitcoinVendingDevices/
Rusty already suggested that a return onion be supplied for refunds, but
I'm not sure if he was talking about a partial onion, or a complete
onion, because that discussion was for the case where the original
payment was sent directly to a non-anonymous payee.
I think in this case though, were a partial onion route is supplied for
the initial payment, the refund payment onion route would have to be a
partial one.
All return onions still have the same problem of capacity though.
>>
>> 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.
> How does the payer derive the payment hash? Or does the payer have to contact the payee again to get a fresh payment hash specifically for the payer?
>
> Regards,
> ZmnSCPxj
>