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