From rusty at rustcorp.com.au  Tue Sep  6 00:49:24 2016
From: rusty at rustcorp.com.au (Rusty Russell)
Date: Tue, 06 Sep 2016 10:19:24 +0930
Subject: [Lightning-dev] Payment presentation strawmen.
Message-ID: <87shtd7syz.fsf@rustcorp.com.au>

Hi all,

        Joseph mentioned the critical issue of how a payee tells a payer
how to pay.   Here's my ordered wishlist:

1) Can be presented with a standard QR code (ie. 1-way comms)
2) Minimal state required on the client.
3) Minimal network queries required by client (ie. minimize privacy leaks).
4) Minimal state required on the server.

Here's a range of possibilities:

A) Simply present amount and public node address, rely on routing protocol for
   client to get there.
   - 4+33 bytes, tiny.  eg. http://ozlabs.org/~rusty/images/QR-04.gif [1]
   - Client has to know entire network, or queries for route/fee
     information which leaks far too much.

B) Present one or more chains of channels from landmarks, with fee info.
   Channels are represented as blocknum & txnum pairs.
   - Adds 4 + 4 + 2 bytes per hop. eg http://ozlabs.org/~rusty/images/QR-11.gif
   - Client needs to know channel tx -> node ID mapping for all nodes.
   - Client must either know routes to landmarks (ie. globally agreed), or
     query for them.

C) As above, but include IDs for each hop in chain.
  - Additional 33 bytes per hop. eg http://ozlabs.org/~rusty/images/QR-21.gif
  - Client must either know routes to landmarks, or query for them.

C is more scalable, OTOH B will work for the first million or so
nodes...

Cheers,
Rusty.
[1] Assuming an average route length of 5, 3 landmarks, and 20 bytes overhead.