Technical: Upcoming Lightning Network Improvement: JIT-Routing (Reddit Bitcoin)
Bitcoin up? Down? Sideways? Who cares? Lightning Network is going LIVE and that’s all that MATTERS! Last time I talked about a bunch of upcoming Lightning Network improvements. They weren’t complete, because there are a big bunch of them being worked on (or mostly just being debated, most devs are fighting bugs and adding boring little features like adding options for various timeouts in communicating with bitcoind and getting their impls out of beta / alpha and etc etc). One thing I’d forgotten about was JIT Routing, which /u/renepickhardt reminded me about. JIT Routing is actually a potentially-viable alternative to multipart payments / AMP, and in particular does not require a BOLT spec update, though does require that most nodes on the network implement it (unlike multipart, which requires only that the payer and payee support it). /u/renepickhardt introduced the idea here: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-March/001891.html I feel this idea is underappreciated — AMP gets all the press — so it deserves its own unique Reddit post! JIT-Routing Rerouting payments by rebalancing just in time to service forwarding requests! Background Now one thing about multipart payments — or even just current, non-multipart payments — is that the payer is mostly just guessing what channels are viable to route through. In the current scheme where payments cannot be split up, payers just do some payment through a route, then if that fails, tries another route, etc etc until it gets paid. For multipart payments, it’s not clear what algorithm to implement, actually. If some route fails, maybe it could work with a lower payment going through it, or maybe not; who knows? The remote node that is sending the failure knows, but it can’t tell the payer: for all it knows, the “payer” is really a spy node that’s trying to trace how much each node owns (for example, as viable targets for the more sophisticated $5 wrench attacks). So all the remote node can safely say is “channel hazy, try again later” (temporary_channel_failure in BOLT terms) which could mean anything from not having capacity to the other endpoint being disconnected to the channel being overloaded with in-flight HTLCs to the node just being lazy today. It can’t say “oh you can only route up to XX millisatoshi in that direction right now” because that immediately leaks how much money it and its counterparty owns in that channel, i.e. a minimum on how much a $5 wrench can extract from both nodes. So since routing is source-based (so that the payer has maximum privacy and able to get around attempts at censorship), the source has to figure out how to get its payment to the destination. But the same principle of privacy-by-default means that the source can’t get information about the capacities of the channels it’s trying to route through, because the intermediate nodes sure as hell ain’t gonna tell. Now the insight in JIT Routing is that the forwarding node has the knowledge of the current channel liquidities of all channels it has. And rather than leaving the details of every routing attempt to the source payer, the forwarding node can instead make local routing decisions based on its knowledge of local channel state. Idea When a node receives a forwarding request it can’t currently serve because of lack of liquidity in the next channel, the node rebalances its funds (by doing a circular self-payment) from other channels it has, to the next channel specified in the route. Yep. That’s all of it. That, in a nutshell, is JIT-routing. It’s probably more accurate to call it JIT-rebalancing. Effect Suppose we have nodes A, B, and C, with channels to each other with roughly equal liquidity on each side. Suppose A has to forward a payment to B, of value 5 mBTC, but it only has 3 mBTC on AB, while it has also 3mBTC on AC. A knows there’s a channel BC. It rebalances via the route A->2mBTC->C->B->A. moving 2mBTC from the channel AC to the channel AB. Once the rebalance completes, A can now perform the 5mBTC forward. This is equivalent to the multipart case where the payer somehow routes 3mBTC via A->B and 2mBTC via A->C->B to deliver 5mBTC to B (which could be the ultimate payee, or another forwarding node). The difference is that the remote payer has to guess, while in JIT routing, A knows exactly what needs to be done to deliver 5mBTC to B. Advantages Doesn’t even need a BOLT spec change: can be done by just adding the feature to implementations without touching the BOLT spec. Rebalancing can already be done now (for a fee), and nodes already have to keep track of how much they own in each channel they have, so there’s no extra spec that has to be created to coordinate how payers and payees work. Each implementation can implement this independently without having to write specs in BOLT (this is a bigger hurdle than it might seem!). No guesswork: the forwarding node knows all the information it needs to do JIT routing. Contrast this with AMP, where the payer somehow magically guesses that it should split its payment across multiple routes. JIT routing is very much like a “local multipart forward” with near-perfect information. Disadvantages Rebalancing isn’t free! If the forwarding node has to pay a fee for the rebalancing, then it runs the risk that, even if it manages forwards the payment, a later node on the route fails the payment and this node doesn’t earn fees, even though it ended up paying fees for the rebalancing. This can be mitigated by measuring the failure rate for forwarding attempts, and only rebalancing if the rebalancing fee won’t exceed the forwarding fee times the probability of success, but that somewhat limits the use of JIT-routing. Rene is working on a proposal for fee-free rebalancing. Fee-free rebalancing might be subject to abuse, since it might be used for paying nearby without fees. Only really becomes beneficial if almost all nodes on the network implement it. Compare this to multipart payments, where even if there are only two nodes that implement it (the payer and the payee) then they get benefits immediately, whereas for JIT-routing, a forwarding node that does JIT routing is likely to experience higher failure rates later in the route from nodes that themselves don’t do JIT-routing, effectively causing the forwarding node to waste money on the rebalancing (see above, Rebalancing isn’t free!).
submitted by /u/almkglor [link] [comments]