Sound promising. My first thought was what happens if one of the peer is offline. The below quote from the PDF seems to address this. There are always trade off but sounds like a force close of the channel could get more expensive then a regular Lightning Channel
B. Channel operations If all peers are online and cooperative, a channel state is updated by simply signing a new version of the allocation transaction, which requires signatures from all channel peers. In case not all channel peers are online or ready to sign a state update, a new operation transaction is created, which spends inputs only of those peers who like to update their state (for instance, make a payment to each other).
Once all the peers are online, they should cooperate and sign a new version of the allocation transaction, which must correspond to the previous allocation transaction with all operation transaction graphs applied on top.
interesting. That could be indeed a game changer.
Here is the original lightning-dev mailinglist post: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-August/004057.html
"In the attachment" where's the attachment???
here: http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230820/bfb41b20/attachment-0001.pdf
The first link didn't work it looks like it was "scrubbed" but the second one leads to a pdf https://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230820/bfb41b20/attachment-0001.pdf
Oh. This is a channel factory
hmmm, I don't know. Its more of a fat channel pool.
Sound promising. My first thought was what happens if one of the peer is offline. The below quote from the PDF seems to address this. There are always trade off but sounds like a force close of the channel could get more expensive then a regular Lightning Channel
Ooooh very nice! Bitcoin development continues to blow me away!
Really interesting!