In this commit, we start to use the new AuxSigner to obtain+verify aux sigs for all second level HTLCs. This is similar to the existing SigPool, but we'll only attempt to do this if the AuxSigner is present (won't be for most channels).
For the initiator, once we get the signal that the PSBT has been
finalized, we'll call into the aux funder to get the funding desc. For
the responder, once we receive the funding_created message, we'll do the
same.
We now also have local+remote aux leaves for the commitment transaction.
In this commit, we modify the aux funding work flow slightly. We won't
be able to generate the full AuxFundingDesc until both sides has
sent+received funding params. So we'll now only attempt to bind the
tapscript root as soon as we send+recv the open_channel message.
We'll now also make sure that we pass the tapscript root all the way
down into the musig2 session creation.
In this commit, we make a new `AuxFundingController` interface capable of processing messages off the wire. In addition, we can use it to abstract away details w.r.t how we obtain a `AuxFundingDesc` for a given channel.
We'll now use this whenever we get a channel funding request, to make sure we pass along the custom state that a channel may require.
This lets us get rid of the mutex usage there. We also shift the algo slightly to increment by 1, then use that as the next value, which plays nicer with the atomics.
In this commit, we start to thread thru the new aux tap leaf structures to all relevant areas. This includes: commitment outputs, resolution creation, breach handling, and also HTLC scripts.
Given the aux leaf store, and a struct that describes the current commitment, we can obtain the CommitAuxLeaves struct, then use that to derive the aux leaves for the commitment outputs and also HTLCs as well.
When restoring commitments and pay descs from disk, we'll store the aux leaves as custom TLV blobs on disk, then use the aux leaf store to map back to the concrete aux leaves when needed.
In this commit, we add the coin selection strategy option to the following
on-chain RPCs `fundpsbt`, `batchopenchannel`, `estimatefee`, `sendcoins`,
`sendmany`, and `sendoutputs`.
In this commit, we update new Taproot related TLVs (nonces, partial sig,
sig with nonce, etc). Along the way we were able to get rid of some
boiler plate, but most importantly, we're able to better protect against
API misuse (using a nonce that isn't initialized, etc) with the new
options API. In some areas this introduces a bit of extra boiler plate,
and where applicable I used some new helper functions to help cut down
on the noise.
Note to reviewers: this is done as a single commit, as changing the API
breaks all callers, so if we want things to compile it needs to be in a
wumbo commit.
With this commit we prepare for the lnwallet channel funding logic to be
aware of the config-level coin selection strategy by adding it to the
wallet config.
* funding: remove unused field `newChanBarriers`
This commit removes the occurance of `newChanBarriers` as it's not used
anywhere.
* funding: rename method names to clear the funding flow
Slightly refactored the names so it's easier to see which side is
processing what messages.
* lnwallet: sanity check empty pending channel ID
This commit adds a sanity check to make sure an empty pending channel ID
will not be accepted.
This commit removes the `Litecoin`, `LtcMode` and `LitecoindMode`
members from the main LND `Config` struct. Since only the bitcoin
blockchain is now supported, this commit also deprecates the
`cfg.Bitcoin.Active` config option.
This tests that the funding manager doesn't immediately consider
a coinbase transaction that is also a funding transaction usable
until the maturity has been reached.
In this commit, we carry out a new notion introduced during a recent
spec meeting to use a feature bit plus 100 before the feature has been
finalized in the spec.
We split into the Final and Staging bits.
Otherwise, in the itests (which are mainly based on implicit
negotiation), we won't try to open taproot chans when we actually need
to.
We may want to revisit this however, since it may lock in parties trying
to use the defaults that aren't currently setting the explicit commit
type during funding.
In this commit, we start to set _internally_ a new feature bit in the
channel announcements we generate. As these taproot channels can only be
unadvertised, this will never actually leak to the public network. The
funding manager will then set this field to allow the router to properly
validate these channels.
In this commit, we add support for the new musig2 channel funding flow.
This flow is identical to the existing flow, but not both sides need to
exchange local nonces up front, and then signatures sent are now partial
signatures instead of regular signatures.
The funding manager also gains some new state of the local nonces it
needs to generate in order to send the funding locked message, and also
process the funding locked message from the remote party.
In order to allow the funding manger to generate the nonces that need to
be applied to each channel, then AddNewChannel method has been modified
to accept a set of options that the peer will then use to bind the
nonces to a new channel.
There is a race condition,
- goroutine_1: performing `stateStep` under `channelReadySent`. Once
`receivedChannelReady` returns true, it will mark the channel state as
`addedToRouterGraph`, which will delete the initial forwarding policy
for private channels.
- goroutine_2: performing `handleChannelReady`, which processes the
remote's channelReady message. It will ask brontide to `AddNewChannel`
in the end.
- goroutine_3: performing `handleNewActiveChannel` in brontide, which
will query the initial forwarding policy and fail to find it because
it's already deleted in goroutine_1.
To fix it, we require `receivedChannelReady` to also check that the
channel's barrier signal in the map `handleChannelReadyBarriers` doesn't
exist, as this signal is removed once `handleChannelReady` finishes
adding the channel in brontide.
This commit is a pure code move. We add a new method
`handleChannelReadyReceived` to handle the channel's state change after
the remote's channel ready message is received.
This commit moves the deletion of the initial forwarding policy to the
end of `stateStep` to make sure the router has persisted it to disk
before the deletion.
