From rusty at rustcorp.com.au Fri Sep 15 03:49:18 2017 From: rusty at rustcorp.com.au (Rusty Russell) Date: Fri, 15 Sep 2017 13:19:18 +0930 Subject: [Lightning-dev] BOLT 11, real time micro payments, and route redundancy In-Reply-To: <59B62689.3020807@AndySchroder.com> References: <59A6316A.2050809@AndySchroder.com> <874lsl93c2.fsf@rustcorp.com.au> <59AB9A0F.9040702@AndySchroder.com> <87o9qr7152.fsf@rustcorp.com.au> <59B62689.3020807@AndySchroder.com> Message-ID: <87shfooc3l.fsf@rustcorp.com.au> Andy Schroder writes: > On 09/03/2017 08:34 PM, Rusty Russell wrote: >> Andy Schroder 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.