Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2016-09-05 📝 Original message: Hi all, Joseph mentioned ...
📅 Original date posted:2016-09-05
📝 Original message:
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. [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
- 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
- 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.
📝 Original message:
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. [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
- 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
- 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.