In this commit, we update the funding workflow to be aware of the new
channel type that doesn't tweak the remote party's output within the
non-delay script on their commitment transaction. To do this, we now
allow the caller of `InnitChannelReservation` to signal if they want the
old or new (tweakless) commitment style.
The funding tests are also updated to test both funding variants, as
we'll still need to understand the legacy format for older nodes.
This commit is a step to split the lnwallet package. It puts the Input
interface and implementations in a separate package along with all their
dependencies from lnwallet.
This reverts commit 4aa52d267f000f84caf912c62fc14a5b8e7cacb5.
It turns out that the other implementations set values for this field
which aren't based on the actual capacity of the channel. As a result,
we'll no reject most of their channel offerings, since they may offer a
value of a max `uint64` or something else hard coded that's above the
size of the channel. As a result, we're reverting this check for now to
maintain proper compatibility.
This commit moves the responsibility for publishing the funding tx to
the network from the wallet to the funding manager. This is done to
distinguish the failure of completing the reservation within the wallet
and failure of publishing the transaction.
Earlier we could fail to broadcast the transaction, which would cause us
to fail the funding flow. This is not something we can do directly,
since the CompeteReservation call will mark the channel IsPending in the
databas.e
In this commit, we fix a bug introduced by the recent change of
lnwire.MilliSatoshi to be an unsigned integer. After this change an
integer underflow was left undetected, as a result we’ll now
momentarily cast to a signed integer in order to ensure that both sides
can pay the proper fee.
This commit adds some more comments and checks to
reservation.CommitConstraints, including making
MinHTLC value one of the passed constraints.
RemoteChanConstraints is also moved out of
reservation.
Before this commit, during a reservation, we wouldn’t ever specify our
minHTL value. We don’t yet fully validate all channel constrains, but
doing this now serves to ensure that once those features are merged,
we’ll actually be setting a valid value for minHTLC.
Adding 99 here didn’t really do anything but obfuscate when we were
trying to compute. We’re just using internet division to calculate 1%
of the channel capacity amount. This is the amount that the remote
party must remain above at all times.
In this commit, we modify the funding reservation workflow slightly to
allow callers to specify their own custom fee when initialization a
funding workflow. This gives power-users the ability to control exactly
how much in fees are paid for each new funding transaction.
This commit adds to methods to the ChannelReservation struct: one for
generating the channel constraints we require for the remote party, and
one for validating their desired constraints, and committing them to
our ChannelConfig.
With these two new methods, we can now begin to properly store and
adhere to the current set of channel flow control constraints.
This commit updates the channel reservation workflow in order to
properly implement the new funding workflow defined in BOLT-0002.
The workflow itself hasn’t changed significantly, but the contents of
the contributions of both sides have. The bulk of the fields within the
contribution of both sides has been boiled down into a pointer to the
ChannelConfig which houses all the data required to handle all states
of the channel, and commitment state machine.
For the two portions which are dictated by the other party, we now add
builder-like modifiers to allow specifying the constraints after the
initial portion of the workflow.
The remote balance in the case of a single funder workflow is simply
what ever the pushSat amount is. The capacity - fundingAmt in this
scenario would always be zero, so we simply just set it directly to
pushSat.
This commit replaces the hard-coded 5000 satoshi fees with calls to the
FeeEstimator interface. This should provide a way to cleanly plug in
additional fee calculation algorithms in the future. This change
affected quite a few tests. When possible, the tests were changed to
assert amounts sent rather than balances so that fees wouldn't need to
be taken into account. There were several tests for which this wasn't
possible, so calls to the static fee calculator were made.
In order to cleanly handle shutdowns and restarts during state machine operation, the fee for the current
commitment transaction must be persisted. This allows the fee to be
reapplied when the current state is reloaded.
In order to make the node's dust limit available to the wallet during
the initial stages of the funding process, add and set a
DustLimit field in the Contribution.
Once a channel funding process has advanced to the point of broadcasting
the funding transaction, the state of the channel should be persisted
so that the nodes can disconnect or go down without having to wait for the
funding transaction to be confirmed on the blockchain.
Previously, the finalization of the funding process was handled by a
combination of the funding manager, the peer and the wallet, but if
the remote peer is no longer online or no longer connected, this flow
will no longer work. This commit moves all funding steps following
the transaction broadcast into the funding manager, which is available
as long as the daemon is running.
In order to facilitate persistence during the funding process, added
the isPending flag to channels so that when the daemon restarts, we can
properly re-initialize the chain notifier and update the state of
channels that were going through the funding process.
This commit ensures that we now properly handle and propagate errors
that arise when attempting to create a new channel after the funding
transaction is believed to be confirmed.
A previous edge case would arise when a user attempted to create a new
channel, but their corresponding btcd node wasn’t yet fully synced.
This commit fixes a prior bug in the wallet triggered by the creation
of a channel using the single funder workflow, but pushing exactly
*half* of the channel over to the other side. The prior logic to
determine who the initiator would result in a disagreement over who
created the channel initially. This wouldn’t manifest until the channel
was attempted to be closed cooperatively. As both side disagreed about
who created the channel they would apply the closing fee to different
outputs, thereby creating mismatched closing transaction. The signature
would fail to validate as the closer will create a different
transaction from that of the responder.
This commit fixes the issue by properly detecting who initially created
the channel.
This commit adds support to the wallet’s internal funding workflow for
pushing a certain amount of BTC to the responder’s side for a single
funder workflow as part of the first commitment.
This commit slightly modifies the channel reservation workflow to
expose the new information conerning the exact confirmation location of
the channel provided by the ChainNotifier. The DispatchChan() method of
the ChannelReservation now also returns the blockHeight and txIndex
where the transaction was ultimately confirmed. This information will
be needed by the fundingManager so it can properly generate the
authenticated channel announcement proofs.
