pull down to refresh

So I was thinking about how to expand Spilman channels to more than 2 participants. Spilman channels suuuck but they work even in ossification, so bears thinking about.
So a Spilman channel works because of the incentives. A Spilman has 2 parties, a designated sender...
...and a designated receiver. Whenever the sender wants to offer more funds to the receiver, it simply signs a new tx with a new division of funds and gives the signature to the receiver.
This is a unidirectional scheme, which suuucks, and worse it is timebound...
...because if the receiver ends up being unresponsive, the sender needs to be able to recover their funds somehow, which is implemented by giving them a timelocked default branch that the receiver, if it is responaive, has to avoid by broadcasting a complete tx for the....
...latest state.
The scheme is unidirectional so as to be incentive-compatible. The sender has no way of closing the channel early, it cannot completely sign any tx (other than the timelocked default branch). The receiver can, since the sender handa over signatures...
...(and the receiver never signs until it decides to close). If the channel is unidirectional, then the latest state is always the one where the receiver has the most money, so logically the receiver will always use the latest state.
Now as I noted before,...
...swap-in-potentiam addresses, when paid onchain, are really Spilman channel opens, because we have timelock covenant opcodes (OP_CSV) now which makes coordination much easier and require less onelineness. And the trick swap-in-potentiam does, is that the receiver...
...(LSP in swap-in-potentiam) does not get paid immediately, but instead gets "paid" by getting a Poon-Dryja channel inside the outer Spilman channel that is the swap-in-potentiam UTXO. The LSP prefers to get SOME channel to it rather than no channel, so the incentive...
...is still that the LSP/receiver prefers the later state where a LN channel exists versus the initial state where a channel does not exist.
As a corollary, any LN participant will prefer a state where it has a larger channel vs one with a smaller channel. So...
..for example, suppose we have a Spilman chan containing a Poon-Dryja chan, and the Spilman chan currently has state sender=1mBTC, Poon-Dryja=1mBTC. If the sender wants, it can then move the state to sender=0, Poon-Dryja=2mBTC, and the receiver is still incentivized...
...to publish the later state, because more LN inbound is better.
So I was imagining, if we can expand the Spilman layer to single-sender-multiple-receiver, we could use that to solve the LSP-last-mile problem. Basically, at the Spilman layer we start with the...
...LSP as the sender, and a bunch of clients as the multiple receivers. We start with all funds in the Spilmam layer owned singlesig by the LSP. When a client needs to receive and has no inbound from the LSP, the LSP reduces its own funds and creates or increases a...
..Poon-Dryja channel inside the Spilman layer to that client. This is still incentive-compatible since the receivers (clients in this case) prefer more inbound to less inbound liquidity, so they would be incentivized to only use the latest state.
So I was humming...
...along those tracks. The REALLY NEAT thing here is that it the LSP does not have to commit funds to ONE specific client, it can commit funds to several clients at once, then only later choose to point funds to a specific client that really DOES need it, AND can..
...increase capacity offchain with no onchain txes because of the extra Spilman layer, ie solve the LSP-last-mile problem.
Except I started doing what I do best which is to think adversarially, and think: what if one of the clients was actually a sockpuppet of...
...the LSP? And that breaks the scheme! IF all the clients were honest they would coordinate to build the receiver-side signatures for the latest state so that the clients can force unilateral exit if the LSP goes haywire, implying every client has possession of...
..completely-signed txes for every state. But if the LSP had one client as a sockpuppet, then the LSP has complete signatures for EVERY state at the Spilman layer, including the first state where it holds all coins, and thus must be trusted to not insert a sockpuppet...
...among the clients. trust-requiring=broken!
So sad. LSP-last-mile 1, ZmnSCPxj 0.
(this is why we need covenants ^^;;)