[Lightning-dev] Trampoline Onion Routing proposal

[Bastien TEINTURIER]

Good morning list,

I have been working on formalizing how trampoline onion routing could work
and just published a PR here
<https://github.com/lightningnetwork/lightning-rfc/pull/611>.
Comments are welcome as this introduces changes at several layers.

Mobile phones are already struggling to keep up with the bandwidth and CPU
requirements to do source-routing.
Trampoline onion routing maintains the same security assumptions (and even
increases the anonymity set) at the
cost of higher fees and timeout values for the payer (and thus more gains
for trampoline nodes).

Here is a high-level summary of the changes required:

   - A new version of the onion packet with a smaller size than v0 (but
   with the same cryptographic operations and security guarantees)
   - A new *node_update* message advertising trampoline fees and cltv
   - New logic to run on trampoline nodes to estimate such fees and cltv
   - A filter system for *channel_updates* and *node_updates*
   - This doesn't change anything to the way HTLCs are forwarded, failed or
   succeeded

Please read the full document for details (and feel free to comment
directly on the PR).

An interesting side-note is that this also enables rendezvous routing and
many other "onion in an onion" constructions.

Cheers,
Bastien
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190523/8fcd70f4/attachment.html>