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. 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. > 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? > > 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. 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
