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

[Andy Schroder]

On 09/03/2017 08:34 PM, Rusty Russell wrote:
> Andy Schroder <info at 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!


Thanks for the clarification on this. So, basically, donations with 
lightening work a lot different from with blockchain donation 
(static/reused) addresses because they can't be re-used? If so, that's 
fine. I always though static donation addresses were a cool idea, but at 
the same time are a huge privacy problem for both parties. Might be 
worth pointing this out in the BIP for newcomers.


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

That would definitely help.

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


Are there any security holes where B or C can receive the offer, but 
pretend they don't and then the payment gets re-routed some other way?


Any way for a party to have multiple hosts for redundancy, like how you 
can have multiple MX and NS records in DNS?


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



It seems to me like this is sort of a limitation in privacy with 
lightening. With blockchain payments on my fuel pump, I could return a 
refund back to the customer without always knowing who they are. With 
lightning, it looks like the payer will reveal their identity to the 
payee by offering a refund payment request. It's great that those along 
the payment route don't know, but it's still bad to have the payer 
revealed to the payee. Why does someone have to reveal their identity 
just to get a refund?


>
> But there needs to be some way for D to tell A it wants a refund
> address, hence a flag in BOLT 11.

I guess it won't hurt to be explicit.

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


Gotcha.

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


Makes sense.


>
> Cheers!
> Rusty.
>