pull down to refresh

How it works

Let's keep it simple: a Lightning channel is basically a Bitcoin 2-of-2 multisig: you have one key, your channel parter has one key, and both signatures are required to move the funds from the multisig address. If you have a 1M sats channel with Acinq, there is a 2-of-2 multisig address between you and Acinq holding those 1M sats on-chain.
The core idea of splicing is that you can change the size of the channel by sending some or all the funds from the multisig to another similar multisig, which will be interpreted as the "same" channel by the Lightning network/protocol.
Want to decrease the size of a channel? Spend from the multisig and only send the amount you want to keep in the channel to the new multisig, and send the rest away (usually your wallet, or your channel partner's address, or both).
Want to increase the size of the channel? Create a transaction that takes as inputs the funds in the multisig and some funds coming from elsewhere, and spends it all to the new multisig address. Et voilà.
Of course, things are a bit more tricky under the hood: every change must be agreed upon by both parties, you need to coordinate, make the network aware of the change, etc., all while not having to trust your channel partner.

What it enables

Splicing is especially cool for Lightning Service Providers (LSPs). It allows them to have only one channel per user and adjust its size, instead of having to open and close channel as their user's transactional needs evolve. It may sounds as nothing, but it's actually quite huge in terms of liquidity and channel management.
Another benefit of splicing is it provides an easy to manage unified balance: a user can have all the funds they ever receive go into one big channel, and just splice-out whenever they need to sends funds on-chain. Here again, huge improvements, both for LSPs and users.
I hope it helps answer some of your questions. Feel free to reach out if something remains unclear!
Will this affect SCB ? Or not at all ?
What are potential risk with splicing tho ?
reply
For SCB you'd just need to update the file accordingly. Nothing to worry about (at least not more than worrying about your SCB lacking some new channel, for example), your node should handle it just fine by itself.
Regarding risks, I'd say they're quite the same as when opening a channel with a peer. The protocol is design to be trustless, and the worst that could happen (apart from unexpected bugs and exploits) is your peer might make you lose some time by pretending they want to splice, whereas they actually don't.
Maybe there are some other risks tho, hopefully someone can chime in if so.
reply