Today I published what I think is a decent channel factory or coinpool design that requires no soft forks. Let me know what you think:
Discussion
To execute this idea would you need a custom lightning implementation or could you just bolt something onto of an existing node? Tried my best to follow but a bit above my IQ
I wrote an implementation that seems to work fine with any LN backend that supports NWC -- I've run it on top of cashu mints, for example. So Reginald doesn't even really node a lightning "node" -- just a wallet that can send and receive LN payments.
I understand that the Lightning Network can operate without third-party risk (assuming one does not make mistakes), but this is a bit difficult to grasp.
Channel factories without a soft-fork? What is this sorcery?
nostr:npub1yxp7j36cfqws7yj0hkfu2mx25308u4zua6ud22zglxp98ayhh96s8c399s is at it again!
How does it compare to John Law's factory designs that also don't require soft forks?
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
Niiiiice… okay okay this is pretty good
nostr:nprofile1qyt8wumn8ghj7un9d3shjtnddaehgu3wwp6kytcpzamhxue69uhhyetvv9ujuurjd9kkzmpwdejhgtcpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszymhwden5te0danxvcmgv95kutnsw43z7qpqv6qjdzkwgaydgxjvlnq7vsqxlwf4h0p4j7pt8ktprajd28r82tvsrp9ptc opinions?
joinstr used by thousands can only fix btc fungibility crisis pointed out by nostr:nprofile1qyt8wumn8ghj7mn0wd68ytndd9kx7afwd3hkctcpramhxue69uhkummnw3ezuum9w35xvmmjwpexjanpvdujucm0d5hsz9nhwden5te0dehhxarj9eux6u3wwfhkx6mn9uq3samnwvaz7tmxd9k8getj9ehx7um5wgh8w6twv5hsz8rhwden5te0dehhxarj9ecx7un5v4kk7mn9wfhjucm0d5hsqgzcatvzlg2m25qffal4leyqfc87wkmhnkl096djq5g7entfumgglyz23f6r
Joinstr v2 will use joinpool with covenants.