In this commit, we modify the mechanics of the wallet to only allow
derivation of segwit-like addresses. Additionally, the ConfirmedBalance
method on the WalletController now only has a single argument, as it’s
assumed that the wallet is itself only concerned with segwit outputs.
In this commit, we modify the way we generate the secrets for
revocation roots to be fully deterministic. Rather than use a special
key and derive all sub-roots from that (mixing in some “salts”), we’ll
use the proper keychain.KeyFamily instead. This ensures that given a
static description of the channel, we’re able to re-derive our
revocation root properly.
In this commit, we modify the funding flow process to obtain all keys
necessary from the keychain.KeyRing interface. This ensure that all
keys we generate are fully deterministic.
In this commit, we update the SignDescriptor struct to instead use the
keychain.KeyDescriptor struct inplace of a raw public key. We do this
as this allows for a recovery mode, where the caller doesn’t know what
key was used exactly, but remembers the precise KeyDescriptor. A
stateless signer is still able to re-derive the proper key, as it’s
given the full path.
The new version of the internal core of btcwallet now uses KeyScopes
rather than address types to derive particular addresses. As a result,
in this commit, we update our API usage to ensure that proper addresses
are still derived.
In this commit, we remove two methods from the WalletController
interface which were previously used by the funding reservation process
(NewRawKey) and the p2p network (FetchRootKey) in order to derive
various keys for operation. This methods are no longer necessary as the
KeyRing interface implements the functionality in a deterministic
manner.
In this commit, due to the recent changes within lnd itself, it may be
possible that a wallet already exists when the wallet has been signaled
to be created. As a result, *always* open the wallet ourselves, but
allow an existing wallet to already be in place.
Adds an extra case to the select statement to catch
an error produced by btcd. The error is meant to signal
that an output was previously spent, which can appear
under certain race conditions in spending/broadcasting.
This caused our final itest to fail because it would
not try to recraft the justice txn.
This commit adds wallet_best_block_timestamp to the gRPC interface.
This is done in order to allow clients to calculate progress while
lnd syncs to the blockchain. wallet_best_block_timestamp is exposed
via the GetInfo() rpc call. Additionally, IsSynced() returns the
WalletBestBlockTimestamp as the second value in the tuple
that is returned, providing additional detail when querying about the
status of the sync. The BtcWallet interface has also been updated
accordingly.
This commit was created to support the issue to
[Add progress bar for chain sync] (lightninglabs/lightning-app#10) in
lightning-app
This commit introduces changes to the validateCommitmentSanity
function to fully validate all channel constraints.
validateCommitmentSanity now validates that the
MaxPendingAmount, ChanReserve, MinHTLC, & MaxAcceptedHTLCs
limits are all adhered to during the lifetime of a channel.
When applying a set of updates, the channel constraints are
validated from the point-of-view of either the local or the
remote node, to make sure the updates will be accepted.
Co-authored-by: nsa <elzeigel@gmail.com>
This commit moves common logic used to calculate the state
of a commitment after applying a set of HTLC updates, into
the new method computeView. This method can be used when
calculating the available balance, validating the sanity
of a commitment after applying a set of updates, and also
when creating a new commitment, reducing the duplication
of this logic.
This commit adds a new boolean parameter mutateState to
evalueteHTLCView, that let us call it without neccessarily
mutating the addHeight/removeHeight of the HTLCs, which is
useful when evaluating the commitment validity without
mutating the state.
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.
This commit adds a test that trigger a case where the balance
could end up being negative when we used the logIndex when
calculating the channel's available balance. This could
happen when the logs got out of sync, and we would use
the balance from a settled HTLC even though we wouldn't
include it when signing the next state.
Appendix C of BOLT 03 contains a series of test vectors asserting that
commitment, HTLC success, and HTLC timeout transactions are created
correctly. Here the test cases are transcribed to Go structs and
verified.
We also break out some logic need to tests that bypass the constructor
and remove some redundant fields.
Before this commit, if the remaining change was small enough, then it
was possible for us to generate a non-std funding transaction. This is
an issue as the txn would fail to propagate, meaning funds could
potentially be stuck in limbo if users didn't manually drop their
transaction history.
To avoid this scenario, we won't create a change output that is dusty.
Instead, we'll add these as miner fees.
Fixes#690.
In this commit, we add the second level witness script to the
HtlcRetribution struct. We do this as it’s possible that we when
attempt to sweep funds after a channel breach, then the remote party
has already gone to the second layer. In this case, we’ll then need to
update our SignDesc and also the witness, in order to do that we need
this script that’ll get us pass the second layer P2WSH check.
In this commit, we add a new witness type to the set of known types.
This new type will be used when we need to sweep an HTLC that the
remote party has taken to the second level.
In this commit, we add a new function that allows a caller to create a
UnilateralCloseSummary with the proper materials. This will be used
within a new sub-system to be added in a later commit to properly
dispatch notifications when on-chain events happen for a channel.
In this PR, we entirely remove the closeObserver from the channel state
machine. It was added very early on before most of the other aspects of
the daemon were built out. This goroutine was responsible for
dispatching notifications to outside parties if the commitment
transaction was spent at all. This had several issues, since it was
linked to the *lifetime* of the channel state machine itself. As a
result of this linkage, we had to do weird stuff like hand off in
memory pointers to the state machine in order to ensure notifications
were properly dispatched.
In this commit, we add a new test case for unilateral channel closes to
ensure that if the remote party closes the commitment on-chain. Then
we’re able to sweep both incoming and outgoing HTLC’s from their
commitment. With this tests, we ensure that the values returned for
HtlcResolutions from the UnilateralCloseSummary are correct and allow
us to sweep all funds properly.
In this commit we add some additional scenarios to the TestForceClose
test. With this expanded test case, we now ensure the the party that
force closes is able to properly sweep both incoming and outgoing
HTLC’s fully with the information contained the HtlcResolution struct.
In this commit, we update the channel state machine tests to use a new
key for each purpose. Before this commit, the same key would be used
the entire time. As a result, a few bugs slipped by that would’ve been
detected if we used fresh keys for each purpose. Additionally, this
reflect the real world case as we always use distinct keys for each
purpose to avoid key re-use.
In this commit, we’ve added a new HtlcResolutions struct to house both
the incoming and outgoing HTLC resolutions. This struct will now be
coupled with the object that returns when we detect that a commitment
transaction was closed on chain. For incoming HTLC’s, we’ll check the
preimage cache to see if we can claim the HTLC on-chain. If we can,
then we’ll copy of the preimage, and make a proper incoming HTLC
resolution.
In this commit, we modify the OutgoingHtlcResolution struct to detect
if this is the remote party’s commitment transaction or not. With this
change, we’ll now be able to properly time out an HTLC that was
detected on the commitment transaction of the remote peer.
Additionally, we now populate the CsvDelay (if local commitment) and
the ClaimOutpoint (as we may be sweeping directly from the commitment
transaction now.
In this commit, we add a new IncomingHtlcResolution struct. This is the
opposite of the existing OutgoingHtlcResolution struct. The items in
this new struct allow callers to sweep an incoming HTLC that we know
the preimage to. These will always be created when a commitment goes
on-chain. However, if we know the preimage, then that will be populated
in place of all zeroes in the Preimage field.
In this commit, we modify both the ForceCloseSummary, and the
UnilateralClosureSummary to return the items needed to sweep the
commitment output distinctly. By doing this, it’s now possible to pass
a dedicated struct to a sub-system in order to allow it to sweep a
commitment output. As the maturity delay is a part of this new struct,
this tells the caller if this was on the local commitment (CSV
required) or on the remote commitment (no CSV required).
In this commit, we’ve added a new method to the channel state machine:
ActiveHtlcs. This method will allow callers to poll the state of the
channel to retrieve the set of HTLC’s active on *both* commitment
transactions.
In this commit, we modify the RevokeCurrentCommitment method to now
return the set of active HTLC’s. This will be used by callers in the
future to update other sub-systems when the set of HTLC’s on the
commitment changes, and can also be used on the RPC level to
synchronize systems level integration tests.
By returning a *TxWeightEstimator from each method, we now all callers
to chain the methods. This adds a bit of nice sugar when interacting
with the struct.
In this commit, we rename several of the existing WitnessType
definitions to be more descriptive than they were previously. We also
add a number of additional types which we need to handle scripts for,
but weren’t yet added before. Finally, we modify the
receiverHtlcSpendTimeout to optionally take an additional parameter to
set the locktime of the spending transaction accordingly. This final
modification allows the caller to specify that the lock time has
already been set on the main transaction.
To implement the BOLT 03 test vectors, a more powerful mockSigner is
required. The new version of mockSigner stores multiple keys and signs
the transaction outputs with the appropriate one.
This commit adds an additional check in GetUtxo that
tests for the nil-ness of the spend report returned by
the neutrino backend. Previously, a nil error and
spend report could be returned if the rescan did not
find the output at or above the start height. This
was observed to have cause a nil pointer dereference
when the returning line attempted to access the output.
This case is now handled by returning a distinct error
signaling that the output was not found.
This commit fixes a nasty bug that has been lingering within lnd, and
has been noticed due to the added retransmission logic. Before this
commit, upon a restart, if we had an active HTLC and received a new
commitment update, then we would re-forward ALL active HTLC’s. This
could at times lead to a nasty cycle:
* We re-forward an HTLC already processed.
* We then notice that the time-lock is out of date (retransmitted
HTLC), so we go to fail it.
* This is detected as a replay attack, so we send an
UpdateMalformedHTLC
* This second failure ends up creating a nil entry in the log,
leading to a panic.
* Remote party disconnects.
* Upon reconnect we send again as we need to retransmit the changes,
this goes on forever.
In order to fix this, we now ensure that we only forward HTLC’s that
have been newly locked in at this next state. With this, we now avoid
the loop described above, and also ensure that we don’t accidentally
attempt an HTLC replay attack on our selves.
Fixes#528.
Fixes#545.
In this commit, we add a new detailed error that’s to be returned
when/if the remote peer sends us an invalid commit signature. The new
error contains the transaction that we attempted to validate the
signature over, the sighs, and the state number. Returning this
additional information will serve to aide in debugging any
cross-implementation issues.
In this commit, add an additional return value to
CompleteCooperativeClose. We’ll now report to the caller our final
balance in the cooperative closure transaction. We report this as
depending on if we’re the initiator or not, our final balance may not
exactly match the balance we had in the last state.
This commit fixes a lingering bug that could at times cause
incompatibilities with other implementations when attempting a
cooperative channel close. Before this commit, we would use a pointer
to the funding txin everywhere. As a result, each time we made a new
state, or verified one, we would modify the sequence field of the main
txin of the commitment transaction. Due to this if we updated the
channel, then went to do a cooperative channel closure, the sequence of
the txin would still be set to the value we used as the state hint.
To remedy this, we now copy the txin each time when making the
commitment transaction, and also the cooperative closure transaction.
This avoids accidentally mutating the txin itself.
Fixes#502.
