How does it compare to John Law's factory designs that also don't require soft forks?
Discussion
That's Timeout Trees, right? I'm not aware of a non-fork version of Timeout Trees. Do you have a link? The attached article by shinobi says Timeout Trees rely on CTV.
It also says the admin must regularly kick everyone out of the current channel factory and put them in a new one. My design tries to make that optional and atypical rather than required.
It sounds like another main difference is that Timeout Trees would use CTV to allow the admin to open channels for his users noninteractively. My design assumes we don't have CTV, so opening the channels happens during a signing ceremony scheduled by the people who want to enter a coinpool together.
https://bitcoinmagazine.com/technical/timeout-trees-a-solution-to-scaling-lightning-network-lsps
No, I'm talking about his Tunable Penalty Protocol. My summary here with links: https://bitcoinops.org/en/newsletters/2023/03/29/#preventing-stranded-capital-with-multiparty-channels-and-channel-factories
Ah, I never saw that, it's a very cool design and now I want to implement a proof of concept
It looks like an advantage of my design is that any participant can get their channel on the blockchain by broadcasting only 2 transaction packages, and from there, an additional 2 transaction packages allow them to force close their channel (so 4 total).
By contrast, based on your 6th diagram it looks like Alice has to broadcast 5 transaction packages to do the equivalent: the first package creates state0 and state0.0, the second makes commitmentA, the third puts her channel AB on the blockchain, the fourth spends from the channel AB plus state0.0 to make commitmentA.A, and the fifth puts the latest state on the blockchain.
It looks like Law's design has one advantages that my protocol does not have: parties within Law's factory can cooperatively rebalance their channels without any onchain transactions -- which I don't know how to do in my design.
Law's design also alerted me to this idea, which I had not thought of but which sounds possible with both of our designs: if 2 or more pool users have near-constant uptime, but they have channel counterparties that are frequently offline, they can create channels with *each other* that are *funded by* the outputs of their channels with the frequently-offline users -- and this allows them to use that money for routing payments even when their counterparties are offline
I did not consider that design when making my coinpool model because I figured only Reginald would have near-constant uptime and the other users would have phone wallets that are usually off. But if I modify my assumptions so that other users can serve as routing nodes within the pool too, I can let them do the thing you described in your article and thus free up more liquidity within the pool.
Thank you for showing me this!
Yes thank you for this