Can someone explain to me how splicing works ? How is this feature will affect current LSP model business ? Is splice in is the same as turbo channel without new channel ? What actualy happened under the hood when a user request to splice out ?
When loop in, utxo are sent to 2-2 multisig and then after several confs the funds can be spent offchain. And then loop out means closing channel ( force close or cooperative ) by publishing the latest channel state, after confirmed the funds will be released onchain
Turbo channel is feature to open channel without onchain conf, so splice in doesn't open a new channel but make the existing inbound liquidity bigger ?

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!
reply
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
At its most basic, splicing allows a node to resize the liquidity on its side of a channel (add funds / spend funds.) It does this by spending the outputs of the old channel into a new channel and adding or subtracting additional funds. The lightning spec now gives a grace period to closing channels to accommodate splices. In the the meantime (6 blocks to confirm and reannounce the newly spliced channel) the old channel state is also maintained just as a precaution and its older capacity limits must still be honored. Once the 6 blocks are up, the spiced channel can be reannounced to the network, the old channel's limitation is removed, and it's like having a new channel with updated capacity.
reply
Hmm seems like i just have to test this by myself, thanks for your time though
reply