Introduction: On The Difficulty Of Predicting The Future ========================================================
What company will have the largest gross earnings next year? If you could predict that consistently, you would likely be able to succeed at stock-picking and already have generational wealth before Bitcoin. Now consider the following question: What Lightning Network node will have the largest influx of payments next year? Consider that a large LSP or custodial wallet would effectively be a corporation, with its clients being shareholders, and will distribute its gross earnings (incoming forwards that go to its clients) to its shareholders (clients). Now do you see the problem with figuring out how to allocate liquidity on Lightning? Allocating liquidity to a channel to a specific node has some similarities to investing in stock with a company. You can always liquidate your allocation, but doing so is costly (closing and opening fees) and if you over-allocate, you potentially lose out on the fees you could have gotten for a particular amount of Bitcoins. Even worse, if you ***under***-allocate, payers will receive errors at your hop, and many extant payer implementations now keep a persistent score. We are asking forwarding node operators to accurately predict the future. We are asking forwarding node operators to be Warren Buffets of Lightning Network. Sidepools ========= Every properly designed piece of user-targeted application software has an "undo" button. If a forwarding node operator mis-allocates its funds, what can it do undo its allocation? Currently, the only thing it can do is to close the channel, which: 1. Is costly 2. Reduces scores that are based on channel age I thus propose a new parallel construction that forwarding nodes can use to ameliorate mis-allocation of funds. A sidepool is nothing more than a Decker-Wattenhofer or Decker-Russell-Osuntokun with N-of-N (N > 2) signers, with forwarding nodes being participants. Crucially, instead of hosting channels inside the Decker-Wattenhofer or Decker-Russell-Osuntokun, channels remain *outside* the mechanism. That is, the actual Lightning Network channels are hosted directly onchain (i.e. the current situation). Instead, the sidepool simply provides HTLC-swapping service to manage the allocation of funds in the actual channels. By keeping Lightning Network channels directly on-chain instead of in a channel factory: * It remains back-compatible with current Lightning Network design, which ***requires*** that gossiped channels have an onchain backing fund that is exactly the channel. * Consider that we are planning a Gossip 2.0 (or is it 20.0 by now??) because someday we might have channel factories. * The transition from Gossip 1.0 to Gossip 22.222 will be difficult; clients which have not upgraded will not see channels hosted in Gossip 22.222, thus reducing the incentive for forwarding nodes to close and reopen channels in order to be hostable in Gossip 22.222. * Existing channels can be reused, retaining any reputational score that a long-lived forwarding node has accumulated. As noted above, the sidepool simply allows the forwarding nodes participating in it to offer, fulfill, and reject HTLCs with each other. The intent is that the HTLCs in the sidepool are used as single-hop peerswaps on channels with participants. Retaining 2-participant channels is useful, instead of expanding channels to have 3 or more participants, because: * Every participant in a N-participant (N > 2) channel would (by necessity, to validate the next state) know of every payment going through the channel. * Thus, we reduce who knows of every payment: only the two participants in a 2-participant channel end up knowing the payment going through it. * That is: HTLCs in the sidepool are only used to manage the liquidity of channels between participants of the sidepool; they are thus a privacy-preserving aggregate of value movements, with individual payments gathered together. * Existing Lightning Network architecture and software maps channels as edges of a graph. * N > 2 channel would require some rethinking of how our software is built, reducing back-compatibility. Thus, sidepools are unpublished. Only the participants in the sidepool (a group of Lightning Network forwarding node operators) care about its existence. Sidepools can be implemented ***today***, with no changes to Bitcoin, by using Decker-Wattenhofer decrementing `nSequence` mechanisms. The drawback is: * Unilateral closes ***SUCK***: * You need a kickoff transaction ***and*** a (long) sequence of transactions. * You need to wait a variable amount of time (it is best to simply be online as long as the maximum time, and you cannot safely be offline for longer than the minimum time). Presumably, the drawback is mitigated if we can reduce unilateral closes of the sidepool: * Forwarding node operators have a strong incentive to have as many 9s of uptime as they can get, reducing unilateral closure due to offline-ness (we hope!). * We still do need to figure out how to improve deferred fee paying (i.e. mempool batching needs to be implemented) or to otherwise prevent closures due to onchain feerate disagreements. Motivations For Using Sidepools ------------------------------- Currently, a Lightning Network channel is effectively a bet that the channel counterparty will be receiving funds: this is precisely the "predict largest gross income" problem. By using a sidepool to help the liquidity of existing channels, a forwarding node operator is instead taking the bet that *at least one* of the other participants in the sidepool will be receiving funds. If a channel is depleted, currently a forwarding node can only open a new channel to the same counterparty, or use an onchain/offchain swap operation. In the close future, it would be possible to splice in funds, but nevertheless this is still an onchain operation, which is costly. But more importantly: past performance is not a guarantee of future performance! Just because a counterparty has been receiving so much that the channel is getting depleted, does not mean that it will *always* be receiving a lot of funds. Economic conditions can change. By putting more liquidity towards a single specific counterparty, the forwarding node operator is effectively doubling down on their bet. While this can be a fairly accurate yet simple heuristic, there is still a black swan possibility that the high demand for liquidity towards that node will evaporate. By instead using a sidepool, a forwarding node operator can reduce the cost. As the sidepool is also an offchain mechanism, swap operations between sidepool and channel are cheaper than between channel and blockchain. The drawback is that the sidepool is limited to a specific set of participants. However, in general a forwarding node will have a small number of high-value counterparties, and if it is in a sidepool with those counterparties, in practice the extra funds in the sidepool can be used to handle more operations. The advantage of putting funds into a sidepool is that those funds can be used to effectively route payments to *any* participant in the sidepool; the forwarding node only needs to ensure that its channels are large enough that it can see the overall trend towards depletion, then trigger a sidepool swap to replenish those funds. Scaling ------- As-is, it seems sidepools do not affect scaling. However, another side-effect of scaling is that large thundering herds of buyers can now be even larger thundering-er herds of buyers. Thus, being able to mitigate any "flash" of liquidity by moving funds quickly to handle such unexpected and unpredicted movements would be a good way to support further scaling. In particular, noting above the issues with upgrading the gossip mechanism, I propose: * Channel factories for end users / graph edges. * No need for gossip change, as end users are not expected to have published channels (unpublished channels delenda est). * Sidepools for forwarding nodes. * Retain existing channels for existing score, back-compat with existing gossip users. Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
