From ZmnSCPxj at protonmail.com Tue Jun 26 07:26:09 2018 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Tue, 26 Jun 2018 03:26:09 -0400 Subject: [Lightning-dev] Including a Protocol for splicing to BOLT In-Reply-To: References: Message-ID: Good morning Laolu, >> but even though it seems technically straight forward t > > Well the full async implementation may be a bit involved, depending on the > architecture of the implementation (see the second point below). > > In the abstract, I'd say a splicing proposal should include the following: > > * a generic message for both splice in/out > * this allows both sides to schedule/queue up possible changes, > opportunistically piggy-backing then on top of the other sides > initiation > * most of the channel params can also be re-negotiated as this point, > another upside is this effectively allows garbage collecting old > revocation state > * fully async splice in/out > * async is ideal as we don't need to block channel operation for > confirmations, this greatly improves the UX of the process > * async splice in should use a technique similar to what Conner has > suggested in the past [0], otherwise it would need to block :( It increases complexity. I suppose it would be OK to limit splice-in so that if a splice-in has not been buried deeply in the chain yet, you cannot splice-in even more, to limit the number of parallel updates you need to keep track of to only 2. > * a sort of pre-announcement gossip messages > * purpose of this is to signal to other nodes "hey this channel is > about to change outpoints, but you can keep routing through it" > * otherwise, if this doesn't exist, then nodes would interpret the > action as a close then open of a channel, rather than a re-allocation At first it seems benign to me -- after all, the channel is simply "reopened" and what does it matter whether other nodes know if the new channel is the same as the old channel? -- but then there will be a time of a few blocks where other nodes consider the channel closed but the replacement channel is not yet deep enough onchain to be reannounced. So I suppose it enables routing across the channel during those few blocks. Regards, ZmnSCPxj -------------- next part -------------- An HTML attachment was scrubbed... URL: