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
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
