<div dir="ltr">Good morning list,<br><br>Before we close this amazing year, I wanted to give you an update and reboot<br>excitement around trampoline routing for 2021.<br><br>Acinq has been running a trampoline node for more than a year to provide simple<br>and reliable payments for tens of thousands of Phoenix [1] users. We've learned<br>a lot and I just opened a new trampoline routing spec PR to reflect that [2].<br><br>The TL;DR is:<br><br>* it's simpler than the previous proposal and more flexible<br>* it makes MPP more cost-efficient and reliable<br>* it works nicely with rendezvous or route blinding<br>* it's as private as normal payments (likely more private) if used properly (details in the PR)<br><br>I strongly believe the current state of trampoline routing can provide great<br>benefits in terms of wallet UX and reliability, but we need more reviews for<br>the spec to converge before it can be broadly deployed without fear of moving<br>parts or breaking changes. Please have a look at the proposal without<br>preconceived ideas; you may be surprised by how simple and natural it feels.<br><br>I also want to stress that the code changes are very reasonable as it re-uses<br>a lot of components that are already part of every lightning implementation and<br>doesn't introduce new assumptions.<br><br>As a matter of fact, an independent implementation has been completed by the<br>Electrum team and has been recently tested E2E on mainnet! Having a spec<br>agreement on feature bits, invoice hints format and onion error codes would<br>allow their wallet to fully interoperate with Phoenix and future trampoline<br>wallets, as well as unblock development of even more improvements.<br><br>Happy end of year to all and stay #reckless in 2021!<br><br>Bastien<br><br>[1] <a href="https://phoenix.acinq.co/">https://phoenix.acinq.co/</a><br>[2] <a href="https://github.com/lightningnetwork/lightning-rfc/pull/829">https://github.com/lightningnetwork/lightning-rfc/pull/829</a></div>