This commit adds a new struct `chanIdentifier` which wraps the pending
channel ID and active channel ID. This struct is then used in
`failFundingFlow` so the channel ID can be access there.
The funding manager has been updated to use `AddPendingChannel`. Note
that we track the pending channel before it's confirmed as the peer may
have a block height in the future(from our view), thus they may start
operating in this channel before we consider it as fully open.
The mocked peers have been updated to implement the new interface method.
The bug manifests when a nil ChannelType is passed to the funding
manager in InitFundingMsg. A default value for ChannelType is selected
and sent in the OpenChannel message. However, a nil ChannelType is
stored in the reservation context. This causes our ChannelType checks in
handleFundingAccept to be bypassed.
Usually this makes us end up in the "peer unexpectedly sent explicit
ChannelType" case, where we can still recover by reselecting a default
ChannelType and verifying it matches the one the peer sent. But if the
peer sends a nil ChannelType, we miss it.
While fixing the bug, I also tried to simplify the negotiation logic, as
the complexity is likely what hid the bug in the first place.
Now negotiateCommitmentType only returns the ChannelType to be used in
OpenChannel/AcceptChannel and the CommitmentType to pass to the wallet.
It will even return a nil ChannelType when we're supposed to use implicit
negotiation, so we don't need to manually set it to nil for OpenChannel
and AcceptChannel.
In preparation for a more complex function signature for set node
announcement, separate get and set so that readonly callers don't need
to handle the extra arguments.
This commit adds a a new `MarshalOutPoint` helper in the `lnrpc` package
that can be used to convert a `wire.Outpoint` to an `lnrpc.Outpoint`.
By using this helper, we are less likely to forget to populate both the
string and byte form of the TXID.
In this commit, a bug is fixed in the funding manager that could result
in the funding process erroring out if the persisted initial forwarding
policy is not found. This could occur if a node restarts after opening a
channel that is not yet fully confirmed and also upgrades their node
from a pre-0.16 version to 0.16 since the values are only expected to be
persisted after 0.16.
With this commit we give the funding manager the ability to inform the
switch about custom channel policies, right after we've announced the
channel to the network.
This change is necessary because before #6753 a channel could only be
opened with the default forwarding policies, so the switch automatically
had the "correct" default values. Since #6753 added the ability to
specify forwarding policies at channel open time, we announced those
policies to the network but never updated the switch to inform it about
the changed policies (previously changing the policies was only possible
through the UpdateChannelPolicy RPC which did call the switch).
In LND v0.15.1, batch_open_channel used p2tr by default
for change output. However, in a later version, a breaking
change has been fixed in FundPSBT to make the change type
configurable (default to p2wkh). As batch_open_channel
uses FundPsbt, we need to put back p2tr as default for
change output
This commit replaces `FundingLocked` found in docs using the following
command,
```shell
find . -name "*.go" -exec sed -i '' 's/FundingLocked/ChannelReady/g' {} \;
find . -name "*.go" -exec sed -i '' 's/FundingLock/ChannelReady/g' {} \;
```
This commit adds a new build tag `integration` and removes the old tag
`rpctest` for clarity. Multiple unnecessary usages of `build !rpctest`
is also removed.
We rename `ChanUpdateOptionMaxHtlc` to `ChanUpdateRequiredMaxHtlc`
as with the latest changes it is now required.
Similarly, rename `validateOptionalFields` to
`ValidateChannelUpdateFields`, export it to use it in a later commit.
This commit, the error returned from `getInitialFwdingPolicy` is checked
in order to avoid a nil pointer dereference panic during the
TestFundingManagerCustomChannelParameters test.
When waiting for the peer to send us FundingLocked, we check whether
we've received this message periodically. This commit changes the
checking interval from 1s to 10ms in itest, which allows us to still
stop the CPU spike while responding to the message quickly.
In this commit, the sanity checks in the CommitConstraints method is
moved out into a helper function called VerifyConstraints. This is done
so that the sanity checks can be performed more easily else where in the
code base. The new helper method is then called in the
handleInitFundingMsg method of the funding manager before the
OpenChannelMessage is sent.
localDiscoverySignals needs to be guarded by its mutex. I was unable to
write a test case that would trigger a race under the race detector, but
better safe than sorry.
This is required by BOLT#07 as otherwise the counter-party will
discard the channel_update as they may not consider the channel
"ready" or reorg-safe. Most other implementations besides eclair
have work-arounds for this, but it is nice to be spec-compliant.
In this commit, we add a new option for the existing confirmation
notification system that optionally allows the caller to specify that a
block should be included as well.
The only quirk w/ the implementation here is the neutrino backend:
usually we get filtered blocks, we so need to first fetch the block
again so we can deliver the full block to the notifier. On the notifier
end, it'll only be checking for the transactions we care about, to
sending a full block doesn't affect the correctness.
We also extend the `testBatchConfirmationNotification` test to assert
that a block is only included if the caller specifies it.
This removes the requirement that the zero-conf channel acceptor
flow use anchors. Also adds a fail-early check for minimum depth
zero in the non zero conf case. It would fail later, but it makes
more sense to fail immediately when receiving AcceptChannel.
feature-bit channels
This allows opening zero-conf chan-type, scid-alias chan-type, and
scid-alias feature-bit channels. scid-alias chan-type channels are
required to be private. Two paths are available for opening a zero-conf
channel:
* explicit chan-type negotiation
* LDK carve-out where chan-types are not used, LND is on the
receiving end, and a ChannelAcceptor is used to enable zero-conf
When a zero-conf channel is negotiated, the funding manager:
* sends a FundingLocked with an alias
* waits for a FundingLocked from the remote peer
* calls addToRouterGraph to persist the channel using our alias in
the graph. The peer's alias is used to send them a ChannelUpdate.
* wait for six confirmations. If public, the alias edge in the
graph is deleted and replaced (not atomically) with the confirmed
edge. Our policy is also read-and-replaced, but the counterparty's
policy won't exist until they send it to us.
When a scid-alias-feature channel is negotiated, the funding manager:
* sends a FundingLocked with an alias:
* calls addToRouterGraph, sends ChannelUpdate with the confirmed SCID
since it exists.
* when six confirmations occurs, the edge is deleted and re-inserted
since the peer may have sent us an alias ChannelUpdate that we are
storing in the graph.
Since it is possible for a user to toggle the scid-alias-feature-bit
to on while channels exist in the funding manager, care has been taken
to ensure that an alias is ALWAYS sent in the funding_locked message
if this happens.
This introduces a BigSize migration that is used to expand the width
of the ChannelStatus and ChannelType fields. Three channel "types"
are added - ZeroConfBit, ScidAliasChanBit, and ScidAliasFeatureBit.
ScidAliasChanBit denotes that the scid-alias channel type was
negotiated for the channel. ScidAliasFeatureBit denotes that the
scid-alias feature bit was negotiated during the *lifetime* of the
channel. Several helper functions on the OpenChannel struct are
exposed to aid callers from different packages.
The RefreshShortChanID has been renamed to Refresh.
A new function BroadcastHeight is used to guard access to the
mutable FundingBroadcastHeight member. This prevents data races.
This commit was previously split into the following parts to ease
review:
- 2d746f68: replace imports
- 4008f0fd: use ecdsa.Signature
- 849e33d1: remove btcec.S256()
- b8f6ebbd: use v2 library correctly
- fa80bca9: bump go modules
In this commit, we switch to always sending a channel type when we're in
explicit mode. This is compatible with prior versions of lnd as they
won't send a channel type, and we'll just arrive at the same type via
the existing implicit funding.
Fixes https://github.com/lightningnetwork/lnd/issues/6067
In this commit, we fix an API inconsistency introduced by a recent fix.
Without this commit, it would be possible for a local user to attempt an
explicit funding type, but then _fallback_ to implicit negotiation if
the remote party didn't have the bit set.
We resolve this by adding a new bit of information to ensure that if
we're the funder and want explicit chan negotiation, we don't settle
for anything less. A new test case has been added to exercise this
behavior.
To recap for posterity, the following issues were found and fixed in the
negotiation logic:
1. If the remote party sent a channel type (in accept channel), but we
didn't, then we would error out. We no longer error out and instead
ensure the channel type they sent matches what we derived via
implicit funding.
2. If the remote party _did not_ have the bit set, but they sent a
chan type (in open channel), we would error out. We no longer error
out, but instead will fall back to implicit negotiation.
Ultimately we want to eventually flip the explicit funding bit to
_required_ to eliminate any other future ambiguities and also ensure
that it isn't possible to inadvertently fall back to implicit funding,
when the _user_ expects explicit funding.
To simplify the message signing API even further, we refactor the
lnwallet.MessageSigner interface to use a key locator instead of the
public key to identify which key should be signed with.
The FundingPsbtFinalize step is a safety measure that assures the final
signed funding transaction has the same TXID as was registered during
the funding flow and was used for the commitment transactions.
This step is cumbersome to use if the whole funding process is completed
external to lnd. We allow the finalize step to be skipped for such
cases. The API user/script will need to make sure things are verified
(and possibly cleaned up) properly.
With go 1.17 a change to the build flags was implemented:
https://go.googlesource.com/proposal/+/master/design/draft-gobuild.md
The formatter now automatically adds the forward-compatible build tag
format and the linter checks for them, so we need to include them in our
code.
This is necessary and is implied by BOLT#02. Both ChannelReserve
parameters should be above both DustLimit parameters. Otherwise,
it is possible for one side to have nothing at stake.
This commit updates call-sites to use the proper dust limits for
various script types. This also updates the default dust limit used
in the funding flow to be 354 satoshis instead of 573 satoshis.
The funding manager doesn't need to know the details of the underlying
storage of the opening channel state, so we move the actual store and
retrieval into the channel database.
In this commit, we modify the existing logic that defaults to implicit
commitment type negotiation to support explicit negotiation if the new
feature bit is set. This change allows us to ditch the notion of a
"default" commitment type, as we'll now use feature bits to signal our
understanding of a commiment type, but allow peers to select which
commitment type they actually wish to use.
In addition, this explicit negotiation removes the need for using the
required bit of any commitment types. Instead, if an implementation
wishes to no longer support a commitment type, they should simply stop
advertising the optional bit.
This commit adds the ability for a channel initiator/responder to
determine whether the channel to be opened can use a specific commitment
type through explicit negotiation. It also includes the existing
implicit negotiation logic to fall back on if explicit negotiation is
not supported.
This field will be examined later down the stack along with the set of
feature bits to determine if explicit channel commitment type
negotiation is possible or not.
