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

Rusty Russell rusty at rustcorp.com.au
Fri Sep 15 03:49:18 UTC 2017


Andy Schroder <info at AndySchroder.com> writes:
> 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.

Yes, lightning is an interactive protocol, whereas bitcoin on-chain
isn't.  As you point out, that leads to problems...

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

No; if I've sent the committed offer, I have to assume you can redeem
it.  Technically we send in batches (offer, offer ... commit) and
c-lightning uses a 10 msec timer so there's a chance to get a failure
before we send the commit.

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

More than possible, but it requires multinode realtime failover, which I
don't think anyone has implemented yet...

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

Indeed, it's deeply suboptimal for privacy.

There's a more complex scheme which is possible, using round-trip
payments (I think this was originally from Christian Decker?); I make a
payment via you and back to myself, it's just that I pay your node an
abnormally high "fee".  But unfortunately for security reasons each
encrypted hop contains the amount it expects to be sent, which doesn't
work if I don't know how much you're going to refund.

Technically, you can put a really small amount in there (each node only
insists that the amount sent is >= this amount), but this just allows
one of those return nodes to untracably steal the extra refund amount.

So, we really need to be able to include a (smaller) return onion to
fix this properly.  I've added that to:

        https://github.com/lightningnetwork/lightning-rfc/wiki/Brainstorming#refunds

Thanks!
Rusty.


More information about the Lightning-dev mailing list