# Would it be possible to standardize a protocol for collaboratively building transactions with other parties, but also in a way that is fully composable across multiple use-cases and participants?
I was watching [this talk](https://youtu.be/b3YpbRzwWj4) on the implementation of Lightning Channel Splicing. It’s something that I’m very excited about, so it’s good to see that it is coming soon™. Dusty describes that the two channel parties will both be able to take the opportunity, while the splice is occuring, to add inputs and outputs to the splice transaction. This makes sense of course, because if both parties want to do a splice at around the same time, it’s better to batch them together into one transaction than to do two separate splices. The way this will work is that they will both take turns adding inputs and outputs, etc., until both are satisfied.
It would be really amazing for the ecosystem to have a widely-adopted, standardized way of collaboratively building transactions, even for non-lightning contexts, which will always work on the fly whenever we need them. I’m sure I’m not the first person to think that, but I don’t know if it’s even possible, so I’m asking. For a motivating example, let me set the stage.
One thing that splicing will allow is that you will be able to make an on-chain payment with your funds that are currently sitting in a lightning channel. What you are essentially doing in the splice is that you are closing the channel cooperatively, making the on-chain payment, and then opening a new channel with the change output. This all happens in the same transaction, so it is an atomic operation. One promising but unintuitive detail is that you can continue to use the channel(s) before the splice transaction has gotten enough confirmations to be considered final (say, 6 confirmations), meaning you can still send and receive lightning payments, and so it doesn’t even interrupt ongoing lightning operations. If you’re interested, [this article](https://blog.muun.com/splices-and-liquidity-in-the-lightning-network/) from Muun explains why that is the case (under the subheading ‘Downtimes’), and the splicing implementation talk at [17:39](https://youtu.be/b3YpbRzwWj4?t=1058).
With Taproot-enabled channels and MuSig2, splice-outs like these will probably also be indistinguishable from regular singlesig spends that a traditional on-chain wallet would produce (assuming it’s a Taproot wallet, of course), i.e. the kind of basic on-chain transactions that we are all already familiar with. This means that it wouldn’t end up costing you more in fees to do this either, compared to what a regular singlesig on-chain wallet would produce. It’s the same as if you never had your funds in lightning, but kept them on-chain in a regular wallet. The spending path that pertains to uncooperative channel closing will not need to be revealed if it is never used. With this, you can truly get a ‘single balance’ experience that is native to the lightning side, where all of your funds are in lightning channels, but you can also pay on-chain just as easily, and it produces identical transactions with all of the same fees as keeping all of your funds in a traditional on-chain wallet. I believe that is the [future vision](https://youtu.be/dgkAX_9-BTM?t=2667) of the Muun wallet, i.e. their roadmap, where the channels are like your UTXOs, but because they’re now channels, not just plain UTXOs, you also get the added benefit that you can do lightning payments using them, increasing efficiency when compared to a regular on-chain wallet. Since this architecture is inherently a multisig wallet, you can also add two-factor authentication for added security, which you might have wanted to use multisig for anyway even if you weren’t using lightning.
Now to my motivating example. Perhaps there is a merchant that accepts on-chain payments, and I want to do a splice-out in order to pay them. But what if that merchant also supports PayJoin ([P2EP](https://blog.blockstream.com/en-bitcoin-privacy-improves-with-btcpay-servers-p2ep-implementation/))? So with PayJoin, the idea is that the merchant will collaborate with you to produce a transaction where they will also add an input into the transaction. Typically, when you pay a merchant with an on-chain singlesig wallet, you just create the transaction by yourself, and you contribute all of the inputs and create all of the outputs by yourself. With [PayJoin](https://en.bitcoin.it/wiki/PayJoin), the merchant also contributes an input of their own to mix things up a bit, and the outputs divvy up the total amount appropriately to the merchant and back to the payer such that the payer ends up paying the same amount as before anyway, but now it’s slightly obscured. The idea is that the common heuristic that all transaction inputs belong to the same person is also broken, so it ends up improving privacy, even for those who don’t use it. If it becomes a widespread practice, the heuristic becomes unreliable, massively improving privacy for everyone.
So I think you can see where this is going. Would it be possible, theoretically, for something like the following to happen?
1. I initiate a splice-out.
2. Me and my channel parter are now collaboratively building a transaction together.
3. One of the inputs to this transaction is just going to be the old channel UTXO.
4. My channel partner takes the opportunity to add more liquidity into the channel, and so they add an input.
5. I then want to add an output that is designed to pay the merchant, but I want to also use PayJoin with the merchant.
6. I now pass this off to the merchant at this stage. Me and the merchant are now collaboratively building a transaction together.
7. The merchant contributes an input, and we decide on the payment output and the change output.
8. I then tell my channel parter about this new input, payment output, and change output. The change output is what is going to be the new channel between us.
9. Finally, me and my channel partner have to exchange the unbroadcasted commitment lightning transactions, which will divvy up the proceeds from the new change output between us appropriately, and can be replaced/revoked over time (i.e. the normal lightning stuff on this new channel).
Can we can compose this into steps such that we don’t need all three people to all explicitly collaborate with each other? As in, they don’t all need to be aware of each other, in order to make this work? Is that the case? It would be really nice if, when on my turn during the splice, I can quickly pass off the transaction to the merchant, who adds an input, and then the merchant sends it back to me. I then use what the merchant sends back to me to tell my channel partner that I want to add said input into the splice transaction. My channel partner doesn’t know that that the input is coming from some other person that isn’t me; they probably just assume that I own that input. It doesn’t really matter, because they don’t need to know. Similarly, the merchant doesn’t know that I’m actually doing a splice collaboration with somebody else from a lightning channel, and that my channel partner is adding an input too. They probably just assume I am a singlesig individual who is just doing a PayJoin with my on-chain funds, and that input is mine, etc. The point is, they don’t need to know. I’m the facilitating person in-between, and I’m the only one who knows.
But is that even true? It really blows your mind when you think about how this could cascade multiple times. What if the input that my channel partner contributed on step 4 actually came from another splice on another channel of theirs? So what essentially happened is that they took the opportunity, during my splice request, to rebalance their liquidity, by reducing it in one of their other channels and increasing it in our channel. They are doing a splice-out on another channel and a splice-in on our channel, all batched into one transaction, essentially. This means that there were actually four contributors to the transaction, one of which I was unaware of. Potentially that fourth contributor could have choosen to add an input or an output too, and I probably would have just assumed that they were being added by my channel partner.
It would be cool if we had a widely-adopted standardized way of doing all of that on the fly, which works with everything, not just with lightning contexts. Anybody running always-online nodes that are paying each other are able to do so much cool interactive payment stuff, theoretically. My only concern about this ‘cascading’ possibility is the latency problems it could impose, I guess. It’s funny to think about, but initiating a splice could theoretically set off a chain reaction of multiple splices from like ten different sources, who all want to take the opportunity to move liquidity around, or who knows what else, and effectively making it into a huge CoinJoin in the end. If that works, that’s bloody amazing, but it might also be annoyingly slow and unreliable. If the latency is bad, and in the worst-case scenario you have to give up on the splice because, from your perspective, you’re just sitting around waiting for somebody else’s turn that doesn’t come in a timely manner, because it’s being passed along from A to B to C to D, etc. In a way, it would be kind of like lightning payments themselves, where the collaborative transaction is being built hop-by-hop across a series of nodes through a kind of function composition, and each node is only aware of their immediate neighbours.
View Reddit by dvide – View Source