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 <[email protected]> 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
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
