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.
Oh. This is a channel factory
hmmm, I don't know. Its more of a fat channel pool.
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
Ooooh very nice! Bitcoin development continues to blow me away!
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
Really interesting!