Add Option Upfront Shutdown #3655

carlaKC · 2019-10-31T12:51:24Z

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 😅

lnwire/lnwire.go

lnwire/accept_channel.go

channeldb/channel.go

fundingmanager.go

discovery/mock_test.go

peer.go

server.go

lnwire/features.go

cfromknecht

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

cfromknecht · 2019-10-31T17:09:54Z

lnwire/accept_channel.go

+	if err != nil && err != io.EOF {
+		return err
+	}
+	return nil


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

lnwire/accept_channel.go

lnwire/shutdown.go

lnwire/features.go

lnwire/accept_channel.go

channeldb/channel.go

fundingmanager.go

carlaKC · 2019-11-01T09:59:23Z

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

lnwire/open_channel.go

halseth · 2019-11-04T13:15:33Z

lnwire/accept_channel.go

+		return err
+	}
+
+	if len(a.UpfrontShutdownScript) == 0 {


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?

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

lnwire/open_channel.go

server.go

fundingmanager.go

Roasbeef · 2019-11-06T03:53:52Z

lnwallet/reservation.go

+
+	errChan := make(chan error, 1)
+
+	r.wallet.msgChan <- &addUpfrontShutdown{


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.

config.go

Roasbeef · 2019-11-06T03:58:24Z

discovery/mock_test.go

+	// embed the peer interface so that mockPeer will implement lnpeer.Peer by
+	// default. Methods that need to be called in tests still need to be
+	// implemented.
+	lnpeer.Peer


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

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 :)

I like this boilerplate-free world :)

Roasbeef · 2019-11-06T04:00:06Z

lnwallet/reservation.go

-	flags lnwire.FundingFlag,
-	tweaklessCommit bool) (*ChannelReservation, error) {
+	flags lnwire.FundingFlag, tweaklessCommit bool, localShutdown,
+	remoteShutdown lnwire.DeliveryAddress) (*ChannelReservation, error) {


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

lnwallet/wallet.go

fundingmanager_test.go

halseth

Latest iteration looks very good!

.golangci.yml

lnwire/features.go

halseth · 2019-11-11T10:26:04Z

discovery/mock_test.go

+	// embed the peer interface so that mockPeer will implement lnpeer.Peer by
+	// default. Methods that need to be called in tests still need to be
+	// implemented.
+	lnpeer.Peer


I like this boilerplate-free world :)

htlcswitch/link_test.go

peer.go

server.go

config.go

peer.go

fundingmanager.go

halseth · 2019-11-11T10:36:59Z

channeldb/channel.go

+	// LocalShutdownScript is set to a pre-set script if the channel was opened/
+	// by the local node with option_upfront_shutdown_script set. If the option/
+	// was not set, the field is empty.
+	LocalShutdownScript lnwire.DeliveryAddress


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?

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.

lnwire/accept_channel_test.go

lnwire/lnwire_test.go

lnwire/accept_channel.go

fundingmanager.go

lnwallet/reservation.go

server.go

halseth · 2019-11-15T13:25:57Z

lnwallet/reservation.go

+	defer r.Unlock()
+
+	r.ourContribution.UpfrontShutdown = shutdown
+	r.partialState.LocalShutdownScript = shutdown


is this necessary to set here?

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 · 2019-11-15T13:27:13Z

fundingmanager.go

+		)
+		return
+	}
+	reservation.SetOurUpfrontShutdown(shutdown)


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

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.

lnwire/lnwire_test.go

feature/default_sets.go

chancloser.go

peer.go

cfromknecht

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

lnwire/features.go

lnwire/accept_channel_test.go

peer.go

cfromknecht · 2019-11-22T22:35:58Z

chancloser.go

-		// Now that we know this is a valid shutdown message, we'll
+		// If the remote node opened the channel with option upfront shutdown
+		// script, check that the script they provided matches.
+		err := maybeMatchScript(


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

chancloser_test.go

cfromknecht · 2019-11-22T22:37:45Z

channeldb/channel_test.go

+		expectedRemote lnwire.DeliveryAddress
+	}{
+		{
+			name:          "No shutdown scripts",


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

cfromknecht · 2019-11-22T22:40:43Z

fundingmanager.go

+	shutdown, err := getUpfrontShutdownScript(
+		msg.peer,
+		msg.openChanReq.shutdownScript,
+		func() (lnwire.DeliveryAddress, error) {


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

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?

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 · 2019-11-27T12:16:32Z

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 · 2019-11-28T17:21:07Z

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).

This commit adds the feature bit and additional fields required in `open_channel` and `accept_channel` wire messages for `option_upfront_shutdown_script`.

This commit enables signalling for the optional upfront shutdown script feature bit.

This commit sets our close addresss to the address specified by option upfront shutdown, if specified, and disconnects from peers that fail to provide their upfront shutdown address for coopertaive closes of channels that were opened with the option set.

This commit adds fields for upfront shutdown scripts set by the local and remote peer to the OpenChannel struct. These values are optional, so they are added with their own keys in the chanBucket in the DB.

This commit gets upfront shutdown scripts from openchannel and acceptchannel wire messages sent from our peer and sets upfront shutdown scripts in our open and accept channel messages when the remote peer supports option upfront shutdown and we have the feature enabled.

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 · 2020-06-13T21:23:33Z

👀

carlaKC requested review from Roasbeef, cfromknecht, halseth and wpaulino as code owners October 31, 2019 12:51

halseth suggested changes Oct 31, 2019

View reviewed changes

cfromknecht reviewed Oct 31, 2019

View reviewed changes

wpaulino removed their request for review October 31, 2019 17:43

carlaKC added the v0.9.0 label Oct 31, 2019

carlaKC mentioned this pull request Oct 31, 2019

lnwire: Support upfront shutdown script feature #449

Closed

carlaKC force-pushed the fundingmgr-optionupfrontshutdown branch from a212935 to 49aa391 Compare November 1, 2019 09:57

joostjager added this to the 0.9.0 milestone Nov 1, 2019

carlaKC requested review from cfromknecht and halseth November 4, 2019 09:17

halseth reviewed Nov 4, 2019

View reviewed changes

Roasbeef requested changes Nov 6, 2019

View reviewed changes

carlaKC force-pushed the fundingmgr-optionupfrontshutdown branch from 49aa391 to a8a3a10 Compare November 6, 2019 13:29

carlaKC requested a review from joostjager as a code owner November 6, 2019 13:29

carlaKC force-pushed the fundingmgr-optionupfrontshutdown branch from a8a3a10 to 1b7c6e4 Compare November 6, 2019 13:35

carlaKC removed the request for review from joostjager November 6, 2019 13:36

carlaKC commented Nov 6, 2019

View reviewed changes

fundingmanager_test.go Outdated Show resolved Hide resolved

carlaKC force-pushed the fundingmgr-optionupfrontshutdown branch 2 times, most recently from a24d0a2 to 3ff97a2 Compare November 8, 2019 15:10

Roasbeef added enhancement Improvements to existing features / behaviour security General label for issues/PRs related to the security of the software spec wire protocol Encoding of messages for the communication between nodes P2 should be fixed if one has time labels Nov 9, 2019

carlaKC mentioned this pull request Nov 11, 2019

Add optional close address #3702

Merged

halseth suggested changes Nov 11, 2019

View reviewed changes

halseth suggested changes Nov 15, 2019

View reviewed changes

carlaKC force-pushed the fundingmgr-optionupfrontshutdown branch from dc6b000 to adf00b8 Compare November 19, 2019 20:01

carlaKC requested a review from halseth November 19, 2019 21:35

carlaKC commented Nov 21, 2019

View reviewed changes

lnwire/lnwire_test.go Outdated Show resolved Hide resolved

carlaKC commented Nov 21, 2019

View reviewed changes

feature/default_sets.go Outdated Show resolved Hide resolved

halseth suggested changes Nov 21, 2019

View reviewed changes

chancloser.go Outdated Show resolved Hide resolved

peer.go Outdated Show resolved Hide resolved

peer.go Outdated Show resolved Hide resolved

cfromknecht reviewed Nov 22, 2019

View reviewed changes

carlaKC force-pushed the fundingmgr-optionupfrontshutdown branch from adf00b8 to ef67638 Compare November 25, 2019 08:49

carlaKC force-pushed the fundingmgr-optionupfrontshutdown branch 2 times, most recently from 0792a15 to e2b0509 Compare November 28, 2019 17:16

carlaKC requested review from Roasbeef, cfromknecht and halseth November 29, 2019 07:22

stevenroose and others added 5 commits December 3, 2019 11:38

lnwire: Add upfront shutdown messages and feature bit

2fb7172

This commit adds the feature bit and additional fields required in `open_channel` and `accept_channel` wire messages for `option_upfront_shutdown_script`.

mulit: Signal support for upfront shutdown

cc7acce

This commit enables signalling for the optional upfront shutdown script feature bit.

channeldb: Add upfront shutdown script to OpenChannel

77222d8

This commit adds fields for upfront shutdown scripts set by the local and remote peer to the OpenChannel struct. These values are optional, so they are added with their own keys in the chanBucket in the DB.

carlaKC force-pushed the fundingmgr-optionupfrontshutdown branch from e2b0509 to 9b35c34 Compare December 3, 2019 09:38

halseth approved these changes Dec 3, 2019

View reviewed changes

carlaKC mentioned this pull request Dec 3, 2019

Set Upfront Shutdown Address via lnrpc/lncli #3786

Closed

4 tasks

cfromknecht approved these changes Dec 3, 2019

View reviewed changes

halseth removed the request for review from Roasbeef December 4, 2019 09:15

carlaKC requested a review from Roasbeef December 4, 2019 09:26

Roasbeef approved these changes Dec 5, 2019

View reviewed changes

Roasbeef merged commit 183797f into lightningnetwork:master Dec 5, 2019

carlaKC deleted the fundingmgr-optionupfrontshutdown branch April 3, 2020 09:21


		errChan := make(chan error, 1)

		r.wallet.msgChan <- &addUpfrontShutdown{

Add Option Upfront Shutdown #3655

Add Option Upfront Shutdown #3655

Uh oh!

Conversation

carlaKC commented Oct 31, 2019 • edited by halseth Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

halseth left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

cfromknecht left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

carlaKC commented Nov 1, 2019

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

halseth left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

carlaKC commented Oct 31, 2019 •

edited by halseth

Loading