Splicing

Splice-in धन जोड़ने वाले पक्ष का बैलेंस बढ़ाता है, जबकि splice-out उसके बैलेंस का कुछ हिस्सा चैनल के बाहर एक आउटपुट में भेजता है। इन योगदानों से कुल क्षमता भी बदलती है; अगर जोड़ने और निकालने की रकम बराबर हो, तो क्षमता पहले जैसी रह सकती है। लेकिन Bitcoin में चैनल का धन जिस आउटपुट में लॉक है, उसकी जगह हमेशा एक अलग फंडिंग आउटपुट आता है। इस बदलाव के लिए सामान्य सहकारी बंदी और फिर चैनल खोलने की ज़रूरत नहीं पड़ती। [1]

पहले चैनल quiescence में जाता है, यानी इस प्रक्रिया के साथ न चल सकने वाले अपडेट कुछ समय के लिए रुकते हैं। शुरुआत करने वाला पक्ष splice_init भेजता है और दूसरा पक्ष splice_ack से जवाब देता है। मिलकर बनाए गए लेनदेन में पुराने फंडिंग आउटपुट को खर्च करने वाला ठीक एक इनपुट और इस चैनल की फंडिंग करने वाला ठीक एक नया आउटपुट होना चाहिए। अन्य इनपुट और आउटपुट से धन जोड़ा या निकाला जा सकता है। इसके बाद commitment_signed और tx_signatures संदेशों में संबंधित हस्ताक्षरों का आदान-प्रदान होता है। [1]

लेनदेन के हस्ताक्षर मिल जाने के बाद भुगतान फिर शुरू हो सकते हैं, भले ही स्वीकार्य संख्या में पुष्टियाँ आने का इंतज़ार जारी हो। इसलिए नोड पुराने फंडिंग आउटपुट, नए splice और संभावित RBF प्रतिस्थापनों से जुड़ी प्रतिबद्धता-स्थितियाँ एक साथ रखते हैं। भुगतान हर सक्रिय संस्करण में वैध होना चाहिए। कनेक्शन टूटने पर अधूरी प्रक्रिया की सही स्थिति बहाल करनी होती है; केवल सबसे आखिरी लेनदेन सहेजना पर्याप्त नहीं है। [1] [2]

दोनों नोड को option_splice के समर्थन पर बातचीत करनी होती है और लेनदेन, शुल्क दर तथा योगदानों पर सहमत होना पड़ता है। दूसरा पक्ष tx_abort भेजकर प्रस्ताव ठुकरा सकता है। जब तक दोनों पक्ष splice_locked से उसी splice की पुष्टि न कर दें, नए अपडेट सभी सक्रिय commitment transactions में लागू होने चाहिए। दूसरे पक्ष का बैलेंस एकतरफ़ा नहीं बदला जा सकता। [1] [3]

Core Lightning ने संस्करण 26.04 में Splicing को डिफ़ॉल्ट रूप से सक्षम किया। इसमें splicein और spliceout कमांड के साथ दो चैनलों के बीच धन ले जाने की cross-splice सुविधा भी आई। फिर भी दूसरे नोड का संस्करण और समर्थित चैनल प्रकार मायने रखते हैं। अलग-अलग वॉलेट में एक ही नाम की सुविधा होने से यह साबित नहीं होता कि उनकी क्षमताएँ समान हैं या वे एक-दूसरे के साथ काम करेंगे। [4]

Splicing भी बिटकॉइन लेनदेन बनाता है, इसलिए ऑन-चेन शुल्क देना और पुष्टियों तथा संभावित पुनर्गठन का ध्यान रखना पड़ता है। उदाहरण के लिए, Eclair में rbfsplice से अपुष्ट splice की शुल्क दर बढ़ाई जा सकती है। चैनल के आरक्षित बैलेंस, पुष्ट इनपुट की शर्तों, योगदानों और बार-बार RBF प्रयासों की सीमाओं तथा बैकअप की स्थिति का ध्यान रखना ज़रूरी है। विशेष मोड option_zeroconf भरोसे से जुड़ी मान्यताएँ बदलता है और प्रोटोकॉल इस मोड में RBF की अनुमति नहीं देता। [1] [5]

जब चुने हुए splice को स्वीकार्य गहराई तक पुष्टियाँ मिल जाती हैं और दोनों पक्ष उसी txid के लिए splice_locked का आदान-प्रदान कर लेते हैं, तो पुराने और असफल संस्करणों को बनाए रखने की ज़रूरत समाप्त हो सकती है। Funding outpoint बदलता है, यानी लेनदेन के किसी खास आउटपुट की पहचान बदलती है। क्षमता दोनों पक्षों के योगदानों के योग के अनुसार बदलती है। सार्वजनिक चैनल में पुष्ट लेनदेन से निर्धारित short_channel_id भी बदलता है और दोनों पक्ष नए announcement_signatures तैयार कर सकते हैं। [1]

दोनों नोड का समर्थन, channel_id, funding_contribution_satoshis का धनात्मक या ऋणात्मक चिह्न और उसकी मात्रा, शुल्क दर, इनपुट, आउटपुट, आरक्षित बैलेंस और हस्ताक्षर जाँचें। RBF के सभी संस्करणों के txid पर नज़र रखें। प्रक्रिया पूरी होने पर splice_locked, नया funding outpoint और सार्वजनिक चैनल का short_channel_id मिलाएँ। यह भी देखें कि HTLC फिर चल रहे हैं और निकासी वाला आउटपुट वास्तव में इच्छित वॉलेट का है। [2] [1]