Splicing

Splice-in은 자금을 넣는 쪽의 잔액을 늘리고, splice-out은 그쪽 잔액의 일부를 채널 밖의 출력으로 옮깁니다. 양쪽의 자금 증감은 전체 용량에도 반영됩니다. 서로 상쇄된다면 용량은 그대로일 수 있습니다. 하지만 비트코인에서 채널 자금이 잠기는 위치는 항상 다른 자금 출력으로 바뀝니다. 일반적인 협력 종료 후 채널을 다시 여는 절차는 필요하지 않습니다. [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는 아직 확인되지 않은 splice의 수수료율을 높이는 rbfsplice를 제공합니다. 채널 준비금, 확인된 입력에 대한 요구 사항, 기여분과 반복 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]