How can you do a bungee transaction (close, pay onchain and open in one tx)?

[artlav]

A common misconception about LN is that it's not real BTC but something else, so i was looking for a way to demonstrate it clearly. I was under the impression that it was conceptually possible to close, pay and open in one transaction and it wasn't done yet only because the wallets haven't got to supporting it, but after a careful look at the specs this does not appear to be so.

What i call a bungee transaction is when you do a mutual close of a channel where you allocate your part of the spending transaction's value into a UTXO to someone you wish to pay on chain, a new channel's funding UTXO and, optionally, a change UTXO. This should save a single tx fee as well as make the user experience more transparent (ideally the user should not need to know, understand or decide which layer the the funds are going to be sent over).

Are there any existing plans for making this type of transaction possible?

If not, what is the rationale for not making it possible? If yes, what is it's googleable name?

As far as i can tell, there are 2 roadblocks in the BOLTs:

1. Minor: open_channel got a option_upfront_shutdown_script optional flag, the use of which make such a closure impossible. How common is it's use in the wild? What is the rationale for it?

2. Major: shutdown does not allow for more than one scriptpubkey, and BOLT 3 does not provide for multiple outputs in closing transaction. This might be amendable by an optional flag?

Am i missing anything else?

[cdecker]

This is covered by my splice-in / splice-out proposal, which indeed we are planning to eventually add to the specification. You describe the splice-out, in which we can perform an on-chain payment directly from the channel's balance. The counterpart is also possible, called a splice-in, which allows you to add funds to an existing channel by shortly dropping on-chain and then recreating the channel, adding funds that were previously pre-locked.

Both should be easy (as long as splice-in pre-locks), but may add some complexity to the gossip protocol, since the newly created channel would remain un-announceable until it reaches a depth of 6, as per spec. This would then mean that local nodes (the participants in the channel) can continue using the channel right away, while remote nodes would prune it from their view due to the funding output being spent, and it'd be unusable for them for 6 blocks.

We are collecting a number of proposals on the wiki (https://github.com/lightningnetwork/lightning-rfc/wiki/Brainstorming#splice-in-out--reanchoring), but it's been neglected a bit as of late. I'd move this discussion to the ML to get more feedback.

[t-bast]

This is possible using the interactive-tx protocol introduced by dual-funding, and used by splicing (#1160).