chanfunding: create new package to abstract over funding workflows #3659
IMO this is out of scope for this PR, I purposefully kept that logic in place in order to not have the PR be too large. The reservation logic is still the bridge between our internal representatio+provisioning of the various channel parmaters (keys, csv delay, sigs, etc) and how things are manifested on the p2p layer (openchannel, acceptchannel, etc). This PR is only about abstracting away how the funding transaction and channel point are obtained by the wallet, and nothing more.
In this commit, we add a new bit to the existing ChannelType bitfield. If this bit is set, then it signals that we have the funding transaction stored on disk. A future change will enable lnd to have the funding transaction be constructed externally, allowing for things like funding from a hardware wallet, or a channel created as a sub-branch within an existing channel factory.
…ackage In this commit, we make an incremental change to move the existing coin selection code into a new chanfunding package. In later commits, this package will grow to serve all the lower level channel funding needs in the daemon.
In this commit, we introduce a series of new abstractions for channel funding. The end goal is to enable uses cases that construct the funding transaction externally, eventually handing the funding outpoint to lnd. An example of such a use case includes channel factories and external channel funding using a hardware wallet. We also add a new chanfunding.Assembler meant to allow external channel funding in contexts similar to how channel factories can be constructed. With this channel funder, we'll only obtain the channel point and funding output from it, as this alone is enough to carry out a funding flow as normal.
…ackage In this commit, we begin to integrate the new channel funding package into the existing codebase. With this set of changes, we'll no longer construct and sign the funding transaction within this package, instead delegating it to the new chanfunding package. We use the new chanfunding.WalletAssembler to carry out all channel funding, providing it with an implementation of all its interfaces backed by the wallet.
In this commit, we make the wallet aware of the second type of funding intent: the ShimIntent. If we have one of these, then we don't need to construct the funding transaction, and can instead just obtain the outpoint directly from it.
…ntext In this commit, we start to thread the pending channel ID from wire protocol all the way down into the reservation context. This change will allow negotiation to take place _outside_ the protocol that may result in a particular chanfunding.Assembler being dispatched.
In this commit, we add a new method `RegisterFundingIntent` that allows a caller to "inject" a pre-populated chanfunding.Intent into a funding workflow. As an example, if we've already agreed upon the "shape" of the funding output _outside_ the protocol, then we can use this to pass down the details of the output, then leverage the normal wire protocol to carry out the remainder of the funding flow.
…eutrino In this commit, we fix a long standing bug within the newly created `verifyFundingInputs` method. Before this commit, the method would attempt to derive the pkScript by looking at the last items on the witness stack, and making a p2wsh output script from that. This is incorrect as typically non of these scripts will actually be p2wsh, and instead will be p2wkh. We fix this by using the newly available `txscript.ComputePkScript` method to derive the proper pkScript. This resolves an issue w.r.t passing incorrect arguments for all backends, but an issue still stands for the neutrino backend. As is, we pass a height hint of zero into the `GetUtxo` method call. With the way the current utxo scanner is set up for neutrino, this'll cause it to never find the UTXO, as it takes the height hint as a UTXO birth height, rather than a lower bound of the birth of the UTXO.