Splicing

Splice-in erhöht das Guthaben der beitragenden Seite; Splice-out verschiebt einen Teil ihres Guthabens auf einen Output außerhalb des Kanals. Die Beiträge wirken auf die Gesamtkapazität. Gleichen sie sich aus, kann diese unverändert bleiben. Die Kanalmittel liegen stets auf einem anderen Bitcoin-Funding-Output. Ein gewöhnlicher kooperativer Abschluss mit anschließender Neueröffnung ist nicht nötig. [1]

Zunächst geht der Kanal in Quiescence über, eine kurze Pause unvereinbarer Aktualisierungen. Der Initiator sendet splice_init, die Gegenseite antwortet mit splice_ack. Die gemeinsam gebaute Transaktion muss genau einen Input haben, der den alten Funding-Output ausgibt, und genau einen neuen Output zur Finanzierung dieses Kanals. Weitere Inputs und Outputs können Mittel hinzufügen oder entnehmen. Danach folgen commitment_signed und tx_signatures mit den entsprechenden Signaturen. [1]

Nach dem Austausch der Transaktionssignaturen können Zahlungen wieder beginnen, während noch auf ausreichende Bestätigungstiefe gewartet wird. Nodes halten deshalb gleichzeitig Commitment-Zustände für die bisherige Finanzierung, den neuen Splice und mögliche RBF-Ersatztransaktionen vor. Eine Zahlung muss für alle aktiven Varianten gültig sein. Nach einer Unterbrechung muss der richtige Zwischenstand wiederhergestellt werden; nur die letzte Transaktion zu speichern reicht nicht. [1] [2]

Beide Nodes müssen option_splice-Unterstützung aushandeln und Transaktion, Gebührensatz und Beiträge akzeptieren. Die Gegenseite kann mit tx_abort ablehnen. Bis beide denselben Splice mit splice_locked bestätigen, müssen neue Aktualisierungen alle aktiven Commitment Transactions berücksichtigen. Niemand kann einseitig das Guthaben der anderen Seite umschreiben. [1] [3]

Core Lightning aktivierte Splicing mit Version 26.04 standardmäßig. Hinzu kamen splicein und spliceout sowie Transfers zwischen zwei Kanälen, genannt Cross-Splice. Trotzdem zählen die Version des anderen Nodes und der unterstützte Kanaltyp. Gleiche Funktionsnamen in verschiedenen Wallets belegen weder identische Möglichkeiten noch Interoperabilität. [4]

Splicing erzeugt weiterhin eine Bitcoin-Transaktion: On-chain-Gebühren, Bestätigung und mögliche Reorganisationen bleiben relevant. Eclair bietet etwa rbfsplice, um den Gebührensatz eines unbestätigten Splice zu erhöhen. Kanalreserven, Anforderungen an bestätigte Inputs, Beitrags- und RBF-Grenzen sowie der Sicherungsstand müssen beachtet werden. Der Sondermodus option_zeroconf verändert die Vertrauensannahmen; das Protokoll verbietet darin RBF. [1] [5]

Hat der gewählte Splice ausreichende Tiefe erreicht und haben beide Seiten splice_locked für dieselbe txid ausgetauscht, können alte und erfolglose Varianten entfallen. Der Funding-Outpoint, also der Verweis auf einen bestimmten Transaktionsoutput, ändert sich. Die Kapazität hängt von der Summe der Beiträge ab. Bei öffentlichen Kanälen ändert sich auch die aus der bestätigten Transaktion abgeleitete short_channel_id; neue announcement_signatures können vorbereitet werden. [1]

Prüfen Sie Unterstützung beider Nodes, channel_id, Vorzeichen und Betrag von funding_contribution_satoshis, Gebührensatz, Inputs, Outputs, Reserven und Signaturen. Verfolgen Sie die txid jeder RBF-Variante. Vergleichen Sie nach Abschluss splice_locked, den neuen Funding-Outpoint und bei öffentlichen Kanälen short_channel_id. Prüfen Sie außerdem den wiederaufgenommenen HTLC-Betrieb und ob der entnommene Output tatsächlich zur gewünschten Wallet gehört. [2] [1]