[Lightning-dev] BOLT 11, real time micro payments, and route redundancy

[Andy Schroder]

Hello,

Yes, it seems as though high frequency payments are not a reality. For 
high value products that are delivered quickly, "micro" payments are not 
even possible. With my fuel delivery system, the smallest volume of 
product that could be individually payed for would be on the order of a 
hundred mL. If I were to implement paying by the 100mL, is there any 
protocol for doing repeated payments? Do you have to request a new 
payment request, or can you just send more to the same payment request?

Regarding the payment route going down, if you can re-use the same 
payment request, when you say *during* a payment, do you mean when you 
are actually sending the payment (I think this is probably it), or 
everything related to that payment request (I don't think this is it)? 
It seems like this could definitely be a problem for lower value 
products that are delivered slowly over long periods of time, such as 
water, natural gas, electricity, internet, a parking meter, or some kind 
of digital content.

Regarding the refund address. Thanks for adding that to the issue 
requests. I guess I'm confused how this is going to work safely. If you 
put a refund request in with your payment, isn't that revealing the 
public key of your node and then defeating the whole purpose of the 
onion routing of the payment in the first place (I'm, assuming the payee 
node re-uses the same public key?)? It seems like rather than putting a 
flag in BOLT 11 to instruct a payer to include a refund payment request, 
shouldn't the payer just know to do that if they think they will need 
to? Or maybe they won't always?

In BOLT 11, how does a payee distinguish payments from different payers? 
In standard bitcoin transactions, this is usually by different bitcoin 
addresses that have been presented to different payers. Is this what the 
purpose of the d and h tagged fields are?

In BOLT 11, in the examples section, for the p tagged field, it lists it 
as a "preimage". Is this supposed to be a "preimage hash"?

In BOLT 11, what's the point of tagged field n if the public key is 
implied through the signature and the required recovery id?

Thanks,

Andy Schroder

On 09/01/2017 11:39 PM, Rusty Russell wrote:
> Andy Schroder <info at AndySchroder.com> writes:
>> Hello,
>>
>> I'm looking through BOLT 11. I don't really see an option for a refund
>> address like is present in BIP 70. Is this intentional? If so, why do
>> you not see that people would possibly want to receive a refund?
> Hi!
>
>          I never even thought of that requirement!
>
>          The payment latency is likely to be in the hundreds of
> milliseconds, making it hard to match with a pump as it normally works
> AFAICT.  People don't appreciate overpaying :)
>
>> I'm trying to adapt my fuel pump
>> (http://andyschroder.com/BitcoinVendingDevices/) to use lightening and
>> it requires a refund address because their is a pre-payment required.
>> Change is then immediately returned at the end of the sale for any
>> unused credit. An alternative is for one's automobile to do real time
>> micro pre-payments, but I'm not sure that the latency of a lightening
>> payment will be low enough and the bandwidth requirement might be too
>> expensive. It would likely also require people's automobiles to measure
>> the product delivered and have an on board wallet. This would be ideal
>> long term, but I'm not sure if it is realistic at this time.
> It's only a problem if the a goes down actually *during* a payment,
> which is a fairly narrow window.
>
> Then it's stuck, and you re-route a new payment.
>
>> Also, assuming that a real time micropayment is doable at the automobile
>> level, what happens if one of your hops goes down in the middle of the
>> product delivery? Can there be automatic alternate/redundant fail over
>> routes like happens with IP traffic? It seems like this could be
>> difficult with onion routing.
>>
>> With all that being said, even if real time micro payments can be a
>> reality, I still see many of other unrelated use cases where there may
>> be a refund desired. I think that's why they put a refund address option
>> in BIP 70.
> I think the logical approach is a flag in BOLT 11 which says it wants a
> refund address, and we put the refund information in the payment onion
> itself.
>
> The refund requires basically another complete BOLT 11 payment
> request, which would be only known to the final recipient.  That won't
> fit in the onion for 1.0, but there's a brainstorming item to allow for
> more information to be crammed in there:
>
>          https://github.com/lightningnetwork/lightning-rfc/wiki/Brainstorming
>
> I've filed a feature request:
> https://github.com/lightningnetwork/lightning-rfc/issues/234
>
> Thanks!
> Rusty.
>