[Lightning-dev] Loop attack with onion routing..

Anthony Towns aj at erisian.com.au
Tue Sep 1 22:01:58 UTC 2015


On 2 September 2015 at 05:48, CJP <cjp at ultimatestunts.nl> wrote:

> The way I see it (and the way it's implemented in Amiko Pay), payer and
> payee (A and H in the scenario) have a direct communication link between
> each other (temporary, for the duration of the payment), to coordinate
> the payment. They exchange things like the hash of R, the to-be-paid
> amount and the address of the meeting point (D).
>

​Okay, I was figuring a *much* more lightweight initiation, essentially
just a one-way ​packet from H (or someone representing H) to A giving hash
of R, amount, and the routable lightning address it needs to get to ("H via
D" maybe). That way you can kick a lightning transaction off by QR code or
NFC as well as over TCP, which I think would be nice. (A printed price tag
could literally be all you need to pay for an item!)

Also, I think it makes it easier for you to add payment-by-lightning to
other protocols; eg if you want your bittorrent client to demand a
lightning payment every 10MB, you can just set it up with a bunch of hashes
to send to peers, and preimages to check to confirm payment, and otherwise
have it operate completely independent of the lightning protocol. ie, it's
just:

  if (peer->balance < 100kb) {
    choose_hash(&peer->payment);
    send("Payment required: R=%s A=%d H=%s", peer->payment.hash, std_amt(),
lightning_route);
    wait_for_preimage(peer->payment.preimage);
    peer->balance += 1MB;
  }
  sent_len = send_block();
  peer->balance -= sent_len

and the lightning stuff can happen entirely out of band -- it only needs to
share the list of hashes and preimages, and agree on the amounts to accept.

​There might be a security benefit there too; even having a tor connection
open to someone gives you more chance of finding a buffer overflow and
taking control of their system than just viewing a QR code they present to
you?​

​Cheers,
aj

-- 
Anthony Towns <aj at erisian.com.au>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150902/3a5e66a8/attachment.html>


More information about the Lightning-dev mailing list