Add Option Upfront Shutdown

[carlaKC]

This PR adds support for option_upfront_shutdown_commitment, which allows nodes to specify a script to which funds should be paid out in the event of a cooperative close during channel negotiation.

Upfront shutdown addresses are set by default for channels that we open or accept if the remote peer supports this feature.

Replaces #449

[halseth]

Did a high level pass, things are coming together! Need to read up more on BOLT-2 before I can give it a more detailed look 😅

[cfromknecht]

@carlaKC solid PR! looks pretty complete to me, well tested and well documented :) completed an initial pass

[cfromknecht]

note to self/spec: adding a TLV field after this seems difficult, as it requires knowing whether or not to expect the delivery address. we might accidentally parse a tlv stream into a delivery address, cc @Roasbeef @joostjager

[carlaKC]

Pushed some small fixes + the ability to enable upfront shutdown a with enable_upfront_shutdown flag.

[halseth]

The spec says

if both nodes advertised the option_upfront_shutdown_script feature:
MUST include either a valid shutdown_scriptpubkey as required by shutdown scriptpubkey, or a zero-length shutdown_scriptpubkey.`

I read this as we must write a zero length field in this case?

[carlaKC]

Checked this out and you're right about the 0 value 👍

So proceeding with the following:

• Encode a 0 for empty shutdown address (fine for non upfront shutdown understanding lnd, will have to double check interop)
• Encode len/addr when given a non-0 delivery address
• Always try to decode with the EOF trick

[Roasbeef]

As there's no real validation going on here (other than the script size), I don't think this needs to go into the wallet. Instead, we can extend the normal contributions to encompass this new piece of information, as after the first two funding flow messages, all the necessary information is known.

[Roasbeef]

Not sure if this is a good move, as it may cause confusion when the interface is extended, but the tests aren't updated and fail. Also tbh, I didn't know this was possible :p

[carlaKC]

My argument for using this is that it results in tests failing loudly. If you extend an interface and a test uses the new function call it will panic, which you'll pick up and have to go see exactly what your change is affecting. If the tests need the new function, you will have to update the mock in your PR (as before), this just saves on some boilerplate :)

[halseth]

I like this boilerplate-free world :)

[Roasbeef]

Following from my other comment, I think this can be handled as a contribution.

[halseth]

Latest iteration looks very good!

[halseth]

I like this boilerplate-free world :)

[halseth]

What do you think about making the methods LocalShutdownScript() fetch directly from the database instead of this pre-populated field? Would it have any downsides?

[carlaKC]

The fields in OpenChannel are also used for writing to the DB, and threading the values through the funding flow (as part of chanState). Since we need the fields in OpenChannel to write it makes sense to read them in/accessin memory?

To keep them out of channel state completely, they'd need to be in ChannelReservation which leaks into lnwallet.

[halseth]

is this necessary to set here?

[carlaKC]

We use the values on partialState when we call SyncPending in handleFundingCounterPartySigs or handleSingleFunderSigs, which both use the ChannelReservation.partialState.

I'm going to update to only set the values on partialState when we write to disk, but I do think it's a bit strange to have these two out of sync with each other. Fine for now, but future changes are going to have to know that this value is not set on partialState.

[halseth]

looks like the shutdown script can be moved to being part of the InitChannelReservation call?

[carlaKC]

Previously got some comments from @Roasbeef about having this data in contributions, which is why it's not in InitChannelReservation.

Having these addresses in ChannelReservation itself requires a method similar to this because we still need to lock the reservation and set the value. I think where we put this (contributions vs reservation itself) may depend on if/how we have plans to decouple funding manager/ wallet, which I don't have the best context for.

[cfromknecht]

@carlaKC latest version is 🔥well tested and easy to follow, only minor comments

[cfromknecht]

is it possible to pull this into a helper so that isn't duplicated?

[cfromknecht]

typically we use all lower cases for test names, not a blocker tho

[cfromknecht]

perhaps extract this closure as a member of the funding manager? can this pass it to both as, e.g., f.genDeliveryAddr

[carlaKC]

Peer already has a genDeliveryScript, so this (as is, and if added to funding manager) results in some duplication. An alternative would be to expose genDeliveryScript on the peer interface, or move all of the logic in getUpfrontShutdownScript into f.genUpfrontShutdown?

[halseth]

I think it is just to avoid some clutter and indentation here, instead having the method be

func(f *fundingmanager) genDeliveryAddr() (lnwire.DeliveryAddress, error) {
			addr, err := f.cfg.Wallet.NewAddress(lnwallet.WitnessPubKey, false)
			if err != nil {
				return nil, err
			}
			return txscript.PayToAddrScript(addr)
}

[carlaKC]

Done some testing to make sure these changes work with other impls/ lnd as is.

lnd:
Branch -> Master: open and close channel ok, does not set upfront for peers that don't support it
Branch -> Branch: local and remote upfront preserved through restart, shutdown addresss checked when appropriate

c-lightning:
Supports upfront shutdown
Open channel from lndl with and without upfront shutdown ok.
Open channel from c-lightning with and without upfront shutdown ok.

C-Lightning does disconnect from us on channel close, but this occurs on master as well, so I'm assuming that's because they only support single channels so do cleanup on close. Will double check.

eclair:
TBD

Just want to clarify the meaning of "MUST fail the connection" in BOLT 2 before requesting review again. Specifically whether we should error out of the close channel interaction or disconnect from the peer entirely.

[carlaKC]

Ecalir interop done, they don't support upfront shutdown so I just checked that channel open/close work as before.

Updated disconnection function call to permanently disconnect from the violating peer by removing them from our persistent peers. We do still have a channel open with the peer, and they will most likely just reconnect to us anyway (since we don't have the ability to ban).

[halseth]

Awesome work, this LGTM now! 💯

Follow-up would be to enable the feature on channel opens. Maybe create an issue for that for someone to pick up? :)

[cfromknecht]

beautiful PR, LGTM 💯

[Roasbeef]

LGTM 💸

[GlenCooper]

👀