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
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev