Andy Schroder <i...@andyschroder.com> writes: > 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?
Not currently, no: paying the same payment request twice is an invitation for anyone in the middle to just take your funds! With 1.1 we're looking at changing the way payment hashes work so this will be possible (kind of like bip32, except for lightning). > 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. No, it's only during the actualy payment. Which looks like: A: Hi B, I'll pay you $1 for preimage of hash X. B: Hi C, I'll pay you $0.99 for preimage of hash X. C: Hi D, I'll pay you $0.98 for preimage of hash X. D: Thanks C, here's the preimage. C: Thanks B, here's the preimage. B: Thanks A, here's the preimage. Now, if B or C go down after receiving the offer but before either failing or returning the preimage, A has to wait, unsure if they'll try to redeem the offer or not. (If B or C are simply offline, A or B simply fail and A gets to try again on a different route). In practice it's a few hundred ms of exposure, but it's still possible. Then we slow down to blockchain speed. > 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? Nobody along the route (B and C in our example above) can see it. And D kind of has to, since it needs to send the refund. But there needs to be some way for D to tell A it wants a refund address, hence a flag in BOLT 11. > 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 this case 'p' is the payment-specific variable. > 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"? Oops, thanks! https://github.com/lightningnetwork/lightning-rfc/pull/235 > 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? I like key recovery, but there were some question marks over it. So if we decide doing key recovery is a dumb idea, we can start using the n field. Since everyone should support it, it's a trivial change. Cheers! Rusty. _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
