Author: Olaoluwa Osuntokun 2018-11-06 07:02:24
Published on: 2018-11-06T07:02:24+00:00
The conversation begins with discussing the limitations of a descriptor language in splicing inputs in a non-blocking way. The participants suggest sending two revocation points for the new commitment when allowing updates to proceed immediately after signing. They note that using existing revocation points for both can extend the leaves of the existing shachain trees.The participants then discuss the idea of using CPFP (Child Pays For Parent) to anchor down splicing transactions, as only one outstanding splicing operation can occur at once. The conversation shifts towards discussing the limitations of c-lightning users opening multiple channels and the idea of increasing max values for these limits if they hit them.The negotiation process for splicing is discussed, along with the limitations of the descriptor language and the possibility of restarting the revocation sequence post-splice to free up space in watchtowers. Both sides are acknowledged to need to modify certain parameters during the channel expansion or contraction process.Adding nested P2SH inputs and allowing sides to set a sig script as well as witness during the signing phase is considered. Maintaining a 1-week CSV when the channel size has dipped from 1 BTC to 100k satoshis is also discussed. The need to send two revocation points for the new commitment is reiterated, one to allow it to be created and another to allow updates to proceed right after signing is completed. Change addresses are considered splice-outs, and all existing HTLCs can be transferred over to the new commitment as additional context.The format of optional fields is discussed, with a suggestion to hold off on them until the formatting is revisited. Lastly, the post-splice reserve is set at 1% of post-splice capacity, which is suggested to be re-negotiated at the time of splice creation rather than being a hard-coded value in the protocol.
Updated on: 2023-05-20T08:46:22.981308+00:00