04-02-2026Price:

The Frontier

Your signal. Your price.

BITCOIN

Splicing protocol merges into Lightning spec to slash fees

Thursday, April 2, 2026 · from 1 podcast
Bitcoin Optech
  • Merged spec enables wallets to adjust channel size without closing them.
  • Early adopters like Phoenix Wallet have already cut user fees by 50%.
  • New engine solves a recursive fee problem that previously broke simple wallets.

Lightning Network developers have finalized a foundational upgrade aimed at simplifying the network’s notoriously complex user experience. The protocol, called ‘splicing,’ is now codified as Bolt 1160 in the official Lightning specification. According to Bitcoin Optech’s Dusty Daemon, a spec merge only happens after rigorous cross-implementation testing - meaning the feature is proven to work across at least three different wallet codebases and is production-ready.

The core improvement is operational. Splicing allows a user to add or remove funds from an existing Lightning channel without having to close it and open a new one. This solves the ‘channel mess,’ where early adopters often managed dozens of small, inefficient channels. The Phoenix iPhone wallet, an early adopter, uses splicing to manage a single channel per user, which cut on-chain fees in half by consolidating transactions.

Beyond consolidation, the upgrade introduces a new transaction engine. Dusty Daemon’s ‘SpliceScript’ logic tackles a thorny recursive fee problem: when a wallet adds more bitcoin to pay for a larger transaction, the transaction size itself grows, requiring yet more fees. The new engine calculates these dynamic fees elegantly, preventing a loop that could break simpler systems.

This engine also enables more advanced moves, like cross-channel splices where funds move directly between two channels in a single on-chain transaction. Developers see this as a foundation for future privacy and efficiency gains, such as batching multiple actions - a splice, a channel open, and an on-chain payment - into one transaction to improve anonymity and reduce costs.

Dusty Daemon, Bitcoin Optech:

- Splicing at its core allows you to change the size of a Lightning channel.

- It is kind of like changing the size of the wings on a plane while it is flying.

While the spec is now set, implementation is the next phase. Core Lightning has already extended its scripting engine to support cross-channel splices, and LND is adding new testing backends. The goal is to make the splicing engine a standalone library, minimizing dependencies and preventing user errors that could lead to lost funds. For the average user, the result should be a Lightning wallet that feels less like managing a fleet of tiny boats and more like using a single, refillable bank account.

LightningProtocolPayments

By the Numbers

  • 1160BOLT numbermetric
  • 50%fee reductionmetric
  • 8450PR numbermetric
  • 8856PR numbermetric
  • 8857PR numbermetric
  • 28.0.4Bitcoin Core versionmetric

Entities Mentioned

Adaptor signaturesProtocol
Bitcoin CoreProduct
Core LightningTool
EclairTool
EltooConcept
FROSTProtocol
Lightning Dev KitTool
LNDTool
PhoenixProduct
SegWitProtocol
TaprootConcept

Source Intelligence

What each podcast actually said

Bitcoin Optech
Bitcoin Optech

Bitcoin Optech: Newsletter #398 Recap • Mar 31

  • Dusty Damon, a long-time contributor, confirmed that BOLT 1160, which merges the splicing protocol into the Lightning spec, has been ratified.
  • A Lightning spec is merged only after a feature is implemented and tested across multiple implementations, analogous to HTML features working on multiple browsers.
  • Splicing was merged into the Lightning spec after successful implementation and testing across three different Lightning implementations.
  • Splicing allows users to change the size of a Lightning channel, which facilitates features like making on-chain payments directly from Lightning funds.
  • The Phoenix iPhone wallet uses splicing to manage a single channel per user, which resulted in a 50% reduction in fees and improved user experience.
  • Large Lightning routing nodes use splicing to balance channels and manage one-way payment flows, potentially more than doubling throughput capacity.
  • Dusty Damon is now working on ancillary features enabled by splicing, such as merging multiple transactions (splices, channel opens, on-chain payments) into a single transaction.
  • Merging transactions via splicing could enhance privacy, reduce transaction costs, and improve blockchain efficiency.
  • Z-Man suggested that focusing on swapping over splicing would have been more efficient due to swapping's smaller block space usage.
  • Dusty Damon acknowledged that 'batch splicing' is challenging, citing difficulties in establishing reputation and preventing malicious actors in multi-party transactions.
  • Core Lightning PR 8450 extends its scripting engine to support cross-channel splices, which involve moving funds between different Lightning channels.
  • A multi-channel splice involves more than one Lightning channel, encompassing actions like cross-channel splices or directing funds to cold storage.
  • Dusty Damon's splicing engine in Core Lightning solves dynamic fee calculation, a complex problem where adding inputs for fees increases transaction size, demanding more fees in a recursive loop.
  • The splicing engine aims to be a standalone library, minimizing dependencies on Core Lightning, and can manage complex channel states, ensuring correct fee rates and balances.
  • The engine prevents potential fund loss scenarios ('foot guns') by preventing users from incorrectly interacting with partially signed Bitcoin transactions (PSBTs) via online services.
  • Core Lightning PRs 8856 and 8857 introduce `splicein` and `spliceout` RPC commands, allowing users to add funds to or remove funds from channels directly.
  • `spliceout` will soon allow sending funds to any Bitcoin address, extending its current functionality of moving funds to an on-chain wallet or another channel.
  • Bitcoin relies on digital signatures (ECDSA and Schnorr) to authorize spends without revealing private keys, using cryptographic math distinct from encryption.
  • Pay-to-Script-Hash (P2SH) further extended commit-reveal by hashing spending conditions in the output and revealing the full script only at spend time.
  • `OP_CHECKSIGFROMSTACK` allows cross-UTXO signature reuse by signing an arbitrary message instead of binding to a specific transaction input.
  • This feature is foundational for rebindable transactions and advanced Layer 2 designs like LN-Symmetry, which could update channel states without old states becoming punishment vectors.
  • Core Lightning 26.04 Release Candidate 1 includes new splicing capabilities and adds an option for 'fronting nodes' in Bolt 12 offers to specify preferred routing peers.
  • Eclair PR 3247 introduces an optional peer scoring system to track forwarding revenue and payment volume, allowing nodes to auto-fund profitable channels or close unproductive ones.
  • LDK PR 4472 fixes a potential fund loss by ensuring transaction signatures are not released until the counterparty's commitment signature is durably persisted, securing channel state.
  • LND PR 10602 adds a `DeleteAttempts` RPC to its `Switch` RPC subsystem, enabling external controllers to manage and remove payment attempt records.
  • LND PR 10481 adds a Bitcoin Core (`bitcoind`) miner backend to LND's integration test framework, allowing tests for Bitcoin Core-specific features like V3 transaction relay.

Also from this episode:

Adoption (11)
  • Mike explained that Bitcoin transactions are public and do not use encryption, which is specifically about hiding information.
  • Bitcoin Core now includes encrypted transport for communication between nodes, encrypting peer-to-peer traffic that was previously in plain text.
  • Bitcoin script gradually evolved to a commit-reveal structure, starting from Satoshi's raw public key design to Pay-to-Public-Key-Hash (P2PKH).
  • Segwit and Taproot refined the commit-reveal approach, with Taproot being the most private by only revealing the specific script path used for spending.
  • Pay-to-Taproot (P2TR) multisig transactions reveal all public keys when spent via a script path due to the requirements of `OP_CHECKSIG` and `OP_CHECKSIGADD` opcodes.
  • For more private multisignatures, key-path spending in Taproot or emerging threshold signature schemes like FROST are viable alternatives.
  • Bitcoin Core version 28.0.4 is a maintenance release that backports bug fixes related to unnamed legacy wallet migration failures that affected version 30.
  • Luke Dash Jr.'s DNS seed was removed from Bitcoin Core (PR #33723) due to non-compliance with DNS seed requirements.
  • Bitcoin Core PR 33259 adds a 'Background Validation' field to the `getblockchaininfo` RPC response for assumed UTXO nodes, providing visibility into prior block validation progress.
  • Bitcoin Core PR 33414 enables Tor proof-of-work defenses for automatically created Onion services, requiring clients to perform work to connect, mitigating attacks.
  • Bitcoin Core PR 34846 adds new functions to the `libbitcoinkernel` C API to easily retrieve `nLockTime` and `nSequence` fields for checking BIP34 rules without manual deserialization.
ProtocolLightning