Subject: Forwardable Peerswaps Introduction ============
[Peerswap](https://peerswap.dev) is a protocol for swapping onchain funds and offchain in-Lightning funds. The intent of this protocol is to allow managing the inbound and outbound capacities of your node without having to perform rebalancing. Rebalancing is arguably a parasitic behavior, preying on low-fee channels to buy out their available capacity, then turning around to resell the purchased capacity at a higher fee. By using swap services instead, a node manager can adjust capacity and effectively add capacity to the network in the needed direction, without pushing their own lack of capacity to a victim. However, a limitation of peerswap is in its name: a peerswap is performed with *only* a direct peer with which you have a channel. This writeup then proposes an extension to the overall peerswap protocol to work around this limitation, which I call "forwardable peerswap". I would like to make the claim that forwardable peerswaps solves the problems that the following previous proposed and deployed solutions attempt to fix: * Liquidity markets (liquidity ads, Lightning Pool, etc.) * Flow control valves (fee-based flow control / passive rebalancing, `htlc_maximum_msat`, etc.) An important part of forwardable peerswaps is that it "hides" a network-health-improving operation in a "channel top-up" operation (i.e. moving onchain funds to Lightning) that net senders will want to do anyway (or else they stop being net senders). Swaps vs. Splices ================= A peerswap and a splice are very similar, in that they change the state of one of our local channels, adding or removing outbound capacity on that channel. However: * A swap will always take 2 onchain transactions: * An offer transaction that has an HTLC output. * A claim transaction that spends the above HTLC output. This spend can take up more space, requiring a SCRIPT revelation, a signature, and a preimage revelation. * If designed to limit onchain footprint, a splice can take just one onchain transaction. * This spend will take only a SCRIPT revelation and two signatures, or with Taproot can be reduced to a single signature without any SCRIPT/Tapscript revelation. Thus, a swap takes more onchain resources than a splice, and if we are considering the state of a *single* channel alone, then a splice is definitely more efficient. However, if a swap extends beyond one hop, then the number of channels affected by the swap is increased. And yet, no matter how many channels are affected, the swap will still take only two transactions. Thus, swapping will exceed the efficiency of splicing once three or more hops are considered. The problem here is that, as indicated by its name, a peerswap is limited to affecting only one channel, a channel between ourselves and one of our direct peers. Now, this limitation of peerswap is not without its justification: * A multi-hop payment is inherently less reliable, as it requires multiple nodes to be continuously online at the same time. * Intermediate LN nodes might not want the change in channel state (i.e. the multi-hop payment might worsen their channel balance). * Offchain-to-onchain swaps impose an economic risk on the acceptor of the swap, which a peerswap can punish by closing the direct channel but which a remote swap cannot punish. Peerswap User Story =================== Suppose we have a small network of nodes A, B, and C, initially with channels perfectly balanced, as all things should be. Suppose however that after some time, A notices that its channel to B has little outbound capacity. A can then propose a peerswap between A and B: A offers some onchain funds in order to change the state in their channel, getting more outbound capacity from A. Suppose B accepts this and completes the peerswap protocol. Now B is in possession of some onchain funds. B then notices that its channel to C has little outbound capacity. B can then propose a peerswap between B and C: B offers some onchain funds in order to change the state in their channel, getting more outbound capacity from B. Suppose C accepts this and completes the peerswap protocol. Now what happens in sum total on the blockchain layer? We will see two swaps, each with 2 transactions, for a total of 4 transactions onchain. Forwardable Peerswap ==================== To improve this, suppose we change the above user story, starting at this point: A can then propose a peerswap between A and B: A offers some onchain funds in order to change the state in their channel, getting more outbound capacity from A. Suppose B then looks up its channels. B then notices that its channel to C has little outbound capacity. B can then propose a peerswap between B and C: B offers some onchain funds in order to change the state in their channel, getting more outbound capacity from B. However, B is really going to act as little more than a message translator between A and C, forwarding peerswap messages from A to C and replies from C to A. Thus, A thinks it is talking to B, but really it is negotiating the peerswap with C, using B as a medium. And vice versa, C thinkgs it is talking to B, but really it is negotiating the peerswap with A, using B as a medium. Further, C itself could end up forwarding the peerswap to yet another node, which itself could forward the peerswap, etc. Yet no matter how many hops the peerswap ends up getting forwarded, there will only be two transactions onchain: one to instantiate the onchain HTLC, another to claim it. The overall changes are: * A should initially offer an onchain HTLC with a longer then expected timeout, so that B (and C, D, etc.) has an opportunity to consider forwarding the peerswap. * B should demand a longer in-Lightning HTLC timeout than what A demands from it (and so on for C, D, etc.). What Peerswaps Are Forwardable? ------------------------------- Let us be absolutely clear that there are actually two sub-protocols of peerswap: * Onchain-to-offchain: An initiator offers onchain funds to get more outbound capacity. * Net senders want to do this. * Offchain-to-onchain: An initiator offers offchain funds to get onchain funds and more inbound capacity. * Net receivers want to do this. Unfortunately, only the first sub-protocol (onchain-to-offchain) is actually forwardable. This is because, in the latter case, the initiator can force the acceptor to waste resources, by aborting the protocol after the acceptor has committed onchain funds to the HTLC. Lightning HTLCs are trivially cancellable, but onchain HTLCs can only be returned by waiting out the timeout and spending onchain fees to recover the funds. In a peerswap, the latter case is fixed by closing the channel with the initiator, thus punishing them for aborting the protocol. However, this punishment cannot be done in the forwarded case without massive channel closures, which turns this into an attack on the network. Thus, forwardable peerswaps can only be of the onchain-to-offchain type that are initiated by net senders. Now you might wonder, how about net receivers, how would they initiate forwardable peerswaps? As I will demonstrate in a much later section, any onchain-to-offchain forwardable peerswaps initiated by net senders will make their way to some net receiver, and thus net receivers need only wait and they will naturally get some kind of forwardable onchain-to-offchain peerswap that will also get them inbound capacity. Future innovations (beyond the scope of this writeup, that is what "future" means) may allow us to develop an offchain-to-onchain remote swap that can effectively punish the initiator if it does not complete the swap. This would allow offchain-to-onchain peerswaps to also be forwardable, which can only be beneficial to the network. This may be hopium, however. Nevertheless, even just forwardable onchain-to-offchain peerswaps are still beneficial, as we shall see in succeeding sections. Advantages Of Forwardable Peerswap ================================== Compared to the current peerswap: * A forwardable peerswap can affect more than just one channel, improving the blockchain space utilization. Compared to multi-hop swaps: * Each node has the opportunity to decide whether to forward the peerswap or not, depending on the states of its other channels. If none of its other channels have a state that would be improved by forwarding the peerswap, the node can end the peerswap forwarding at itself and just accept the onchain funds. * There is still the issue of multiple nodes having to coordinate in order to finish the forwarding and complete the protocol. Hopefully, for nodes used often on the public network, uptime should be high, and nodes can monitor peer uptime and use this information to decide whether to forward a peerswap to a particular peer or not. In particular, we can also compare forwardable peerswaps to standard forwardable payments on Lightning: * Forwardable payments are source routed for privacy of the payer (and some minor privacy of the payee). * Due to the source not having access to the private information of intermediate nodes, it cannot know if the intermediate nodes would like the change in capacity, or if the intermediate nodes even *have* the correct capacity. * Forwardable peerswaps are effectively packet-routed, with each node deciding where exactly to forward (or to not forward) each peerswap. * Each node has perfect information on which of its channels would appreciate the change in capacity, and also perfect information on which of its peers is online right now, who has high uptime, etc. Fees And Incentives For Individual Nodes: Why Net Receivers Still Benefit ========================================================================= A node forwarding a peerswap should not charge a fee for the forward. Any fee that the peerswap initiator may offer should be paid, in full, to the ultimate acceptor of the forwarded peerswap. Consider a node that forwards an incoming peerswap request, instead of accepting it itself. That node: * Gets *two* of their channels balanced better. * Does not have to perform any onchain activity. In short, it gets a free rebalance. That is enough incentive, as the intermediate node can expect more future income from having two channels with improved balance, and does not have to spend anything on onchain activity. The forwarding node will, if it is rational, forward it over a channel that lacks outgoing capacity. This translates to forwarding it to a next hop that has low incoming capacity. If there are net senders and net receivers in the network, then the senders will deplete their on-Lightning funds on all their channels. If a net sender depletes their on-Lightning funds: * If the net sender can no longer acquire funds, they stop being a net sender and we can ignore them. * If the net sender can acquire funds and get them on Lightning, they stop being a net sender and end up being neutral to the network, since the funds they can send out must be less than or equal to the funds they receive. They stop being a net sender and we can ignore them. * If the net sender can acquire funds and get them onchain, they can use the onchain funds ot initiate onchain-to-offchain peerswaps. If *all* net senders have depleted their funds and can no longer get funds from either Lightning or onchain (i.e. nobody starts a forwardable peerswap), then net receivers will not receive more funds anymore anyway (nobody is getting more funds to send) and the fact that they have insufficient inbound capacity is immaterial, so the fact that they cannot initiate a forwardable peerswap is not a problem. Now let us focus on a net receiver. A net receiver is one where the payment flows are, in sum, towards them. This implies that, without further channel creations, the inbound capacity they have will be depleted. This also implies that they have much too large outbound capacity, due to how channels work. A net receiver is therefore a node with too much outbound capacity. Suppose net sender uses a peerswap that can be forwarded. Then its direct peer has an incentive to look at its other channels to forward the peerswap to, so that it gets two channels rebalanced for free without having to be responsible for an onchain UTXO. Now, suppose the forwardable peerswap reaches a node who finds that it cannot forward the onchain-to-offchain peerswap anymore. This would occur if the node has too much outbound capacity, and cannot add more outbound capacity with its peers. Now recall that a node with too much outbound capacity is a node that has too little inbound capacity. And a node with too little inbound capacity is a net receiver. Thus, forwardable peerswaps will start at net senders and will be naturally pathed to terminate at net receivers. This is the advantage of forwardable peerswaps being packet-switched instead of source-routed. (Yes, problems and other things can occur along the way and the real world and so on, but considered in an ideal world, forwardable onchain-to-offchain peerswaps will naturally path from net senders to net receivers.) Comparison To "Just Make A Channel" =================================== Suppose a net sender just looks at it history of payments and makes a direct channel to a node that it usually pays to anyway, using its cold-storaged onchain UTXO to fund the new channel. This heuristic would probably work, but note that just because a net sender is paying a node, does not mean that *that* node is itself a net receiver! Merchants have to pay: * Suppliers of raw materials. * Employees. * Shareholders and owners of the business. In a future where everyone gets paid over Lightning, it is likely that merchants you pay to may themselves not even be net receivers of money over Lightning. In that case, the "just make a channel" technique will cause capital to be locked inefficiently, since the merchant that the net sender is paying is not really a net receiver, and the added capacity towards them would be underutilized. A forwardable peerswap, because of the incentive of each individual hop, will eventually locate the *actual* net receivers and thus forward the needed capacity adjustments to those receivers, even if the net sender does not know who the *real* net receivers on the network are. Thus, forwardable peerswaps will allocate capital more efficiently, simply by following the incentives of each individual public routing node. Further, if the net sender regularly uses unpublished channels, then the capacity they add to the merchant they usually pay is not even utilizable by the rest of the network. However, if a forwardable peerswap is used, even if it starts at an unpublished channel, it can be routed out over the public network and thus have the capacity utilized by the rest of the public network. If the net receivers of the network are *also* using unpublished channels, then the forwardable peerswap can also still reach them, since their direct peer still knows about them and can decide to forward the peerswap to them. Thus, forwardable peerswaps can adapt to a world where unpublished channels have not been delere sufficiently. On Liquidity Markets -------------------- There are various liquidity markets already deployed or being developed. These liquidity markets are intended to make the "Just Make A Channel" strategy be guided better, by having net receivers somehow directly contact net senders so they can make direct channels and get the needed capacity. However, this often means that additional information must be broadcast and/or additional resources kept in reserve. * With e.g. Lightning Pool, net receivers must provide their contact information and inbound capacity needs to a centralized server, which can be attacked or taken over to filter out particular, identified net receivers (i.e. censorship). * With e.g. liquidity ads, there is no central server, but all forwarding nodes have to broadcast their liquidity ads, and all forwarding nodes have to keep some funds in onchain reserve, in case a new net receiver wants to buy liquidity from them. Finally, liquidity markets are often targeted at getting net receivers in touch with forwarding nodes. But ideally, forwarding nodes have an almost net zero flow on the network, and what needs to really be matched up are net senders to net receivers. Presumably forwarding nodes that participate in liquidity markets are hoping that net senders will randomly build channels to them, but that is not assured and a net receiver that matches up with a forwarding node may find that the forwarding node has actually oversold its inbound capacity. What needs to *actually* be done is match up net receivers to net senders. In contrast: * In forwardable peerswaps, nobody knows who the net receivers are. A direct peer of a net receiver might forward a peerswap to them, but if the net receiver has other channels, that peer cannot be sure it terminates to them or is further forwarded. Thus, not even direct peers of a net receiver can learn that they *are* a net receiver. * Even if a direct peer of the net receiver somehow knows them for a net receiver, they have disincentive to "filter out" the net receiver: they would not earn fees from the channel with the net receiver. If they wanted to impede the net receiver from being paid, they should have just closed the channel with them instead of maintaining it. But the net receiver can then go connect to some other node that still supports forwardable peerswaps, because decentralization, and thus cannot be censored without a network split. * Purely forwarding nodes never need to maintain any onchain funds --- they will just forward peerswaps through them and gain the benefit of having two channels better balanced without having to touch onchain funds. This is unlike liquidity ads, which requires that liquidity ad-broadcasting forwarding nodes keep a stock of onchain funds to service dual-funding requests. This lets forwarding nodes maximize their on-Lightning funds for more earnings, without having to speculatively reserve some funds onchain, as in the liquidity ads case. * Forwardable peerswaps, due to being packet-switched, will naturally gravitate from net senders to net receivers, with almost-net-zero forwarding nodes naturally pathing them from the former to the latter. This effectively forms a matchmaking between them. While forwarding nodes want to be mildly net receivers, the expected earnings are tiny and it would be likely a long time before their inbound capacity is depleted, and if so, they can then terminate a received forwardable peerswap at themselves, just like any other net receiver. Comparison to "Rebalance Rebalance Rebalance" ============================================= Currently, forwarding nodes manage their balances via rebalancing, i.e. making a self-payment, from a channel with high outgoing capacity to a channel with low outgoing capacity. Because the fees they earn on Lightning are very small, such forwarding nodes will select rebalancing routes with low fees, and will have strict budgets on how much they are willing to spend on rebalancing. What then happens is that random altruists who set their fees to very low, or even zero, will find that forwarding nodes will keep rebalancing via their channels. As multiple forwarding nodes vie for the limited amount of capacity on such low-fee channels, by the time an actual economic-activity non-rebalancing payment reaches one of those altruist nodes, the available balance towards net receivers has been depleted, having been transferred to rebalancing forwarders, leading to payment failure and longer payment settlement times. Thus, rebalancing forwarders who want to turn a profit, end up (deliberately or not) exploiting altruists who are setting their fees too low. (Though since altruists will often say that they are doing this "to help the network", we should note that the profiteering forwarding nodes *are* component parts of the network, so the altruists have in fact achieved their stated goal. It would be different if the actual goal was "to help payers pay cheaply", which is not achieved.) Now consider a world where forwardable peerswaps is widely deployed on the network, and widely initiated by net senders to top up their channels. In that world, if a forwarding node receives a forwardable peerswap, they can rebalance two of their channels favorably without spending anything. A self-paying rebalance would still need to pay out fees. Even if a rebalancer is exploiting a zero-fee-routing node, it is likely that one or more of the nodes between it and the exploited altruist will charge a non-zero fee. Thus, there will still be a cost to a self-paying rebalance. In contrast, accepting and forwarding a forwardable peerswap would gain the same benefit as a successful rebalance (fix the balance of two channels), but at zero cost to the forwarder. A self-paying rebalance does have the advantage that it can be performed at any time, whereas forwarding a forwardable peerswap requires waiting for an opportunity to do so. But if forwardable peerswaps are widely deployed on the network and happen often enough, then it may be sufficient that forwarders find that active self-paying rebalancing is no longer sufficiently advantageous, and that behavior is therefore suppressed. This should then lead to a world where the exploitation of those altruists charging low fees for their capacity is greatly reduced, since active self-paying rebalancing is no longer particularly needed by profiteering forwarding nodes. Comparison To "Flow Valves" =========================== Due to channel depletion causing payment delays, there are proposals for some kind of "flow valve" to modulate payment flows on the Lightning Network. * Fee-based valves broadcast feerates to signal how much outbound capacity is in a particular direction, to entice users to the channel via low fees, or drive away users (and reduce flow) via high fees. * `htlc_maximum_msat` valves broadcast changes to that advertised parameter to change how much payment flow goes through a channel. * This is unfortunately broken as users can split their payments (or self-paying rebalances, for that matter) to below the `htlc_maximum_msat`, and thus get around the flow valve. This can be fixed by using a sufficiently high non-zero base fee, but that is arguably switching over to a fee-based flow valve. In both cases, flow valves not only have to be widely broadcast across the network (increasing bandwidth consumption) but it also leaks information about the capacity of channels of the forwarding nodes, and thus indirectly leaks information about who net senders and net receivers are (by observing which flow valves are the more limiting). But more importantly, flow valves increase the friction of using Lightning Network. If the friction is high enough, users will switch to another payment network. Rather than install flow valves (which would slow down LN payment velocity) we just make forwardable peerswaps as a pressure release valve, releasing pent-up pressure-to-pay by diverting it on a swap over the base Bitcoin blockchain. This effectively admits that we *do* need to switch over to another payment network once Lightning starts getting overloaded. Basically, a forwardable peerswap is a payment, from some net sender to some net receiver, over the Bitcoin blockchain (i.e. the "another payment network") rather than over Lightning. However: * A net sender may be matched up to an arbitary net receiver that is physically nearby on the Lightning Network, but which the net sender does not, in fact, have direct economic ties with. Thus, onchain surveillors cannot derive any information from this onchain payment, other than "looks like the Lightning Network is busy today". * A succesful forwardable peerswap is a pressure release valve, which resets the state of multiple channels on the network, from net senders to net receivers, and thus enabling further payment flows involving them and their neighborhood. There is thus no need for a flow valve. * There is no need to broadcast anything, and forwarding nodes do not need to leak their channel balances over the gossip network. * Users are already conditioned to accept that onchain activity is costly, but have been convinced that Lightning is cheaper and faster. If flow valves are used, they may cause Lightning to work slower and more expensively, thus breaking that expectation. But if forwardable peerswap is used instead, users who use onchain funds to "top up" their channel end up initiating a forwardable peerswap that keeps the rest of the network cheap and fast, while accepting that the onchain activity involved in this will be costly and slow since that is what onchain activity inherently is. _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev