Tis commit makes the btcwallet signer implementation use
signDesc.HashType instead of SigHashAll when signing
transactions. This will allow the creator of the transaction
to specify the sighash policy when creating the accompanying
sign descriptior.
In this commit, we fix an existing derivation from the commitment state
machine as defined within the specification. Before this commit, we
only kept a single counter which both HTLC adds and fails/settles would
share. This was valid in the prior pre-spec iteration of the state
machine. However in the current draft of the spec, only a distinct
counter for HTLCs are used throughout.
This would cause an incompatibility, as if we mixed adds and settles
during an exchange, then our counter values would differ with other
implementations. To remedy this, we now introduce a distinct HTLC
counter and index within the updateLog.
Each Add will increment both the log counter, and the HTLC counter.
Each Settle/Fail will only increment the log counter. Inbound
Settle/Fails will index into the HTLC index as to target the proper
HTLC. The PaymentDescriptor type has been extended with an additional
field (HltcIndex) which itself tracks the index of an incoming/outgoing
HTLC.
This moves the commitment transaction generation code out of
fetchCommitmentView into createCommitmentTx. Aside from being a pretty
clean logical split, this allows the transaction generation code to be
unit tested more effectively.
This commit fixes the TestChannelBalanceDustLimit unit test in
channel_test.go. The unit test does not account for the fees
required by adding an HTLC. As a result, Alice's balance according
to her local and remote commitment chains drops below 0 at certain
points. By using the correct fee, this is avoided.
The fee estimation for funding transactions now properly accounts for
different types of UTXOs spent, whereas previously it assumed all
inputs were spending native P2WKH outputs.
Use binary.Read/Write in functions to serialize and deserialize
channel close summary and HTLC boolean data, as well as in
methods to put and fetch channel funding info. Remove lnd
implementations of readBool and writeBool as they are no
longer needed. Also fix a few minor typos.
Use sort.Slice in SignNextCommitment function in lnwallet/channel.go,
as part of the move to use new language features. Remove
sortableSignBatch type wrapper for slice of signJobs since it is
no longer needed to sort jobs according to their output indices.
Also fix a few minor typos in channel.go and sigpool.go.
This commit fixes an existing bug where we attempted to re-use the same
commitTweak value when creating an HTLC resolution. Instead, we now
create the commit tweak value factoring the key that is to be used for
signing.
In this commit, we extend the help message for `newaddress`
to indicate which address types can be used when directly
funding channels. Additionally, we add some additional text
to the insufficient funding error to detail that we don't have
enough witness outputs.
This commit expands the existing TestForceClose test case to add an
HTLC (outgoing) to Alice’s commitment transaction before force closing.
We then ensure that both the pre-signed timeout transaction _and_ the
sign descriptor to sweep the second-level output are fully valid.
This commit fixes an existing bug within extractHtlcResolutions. The
prior code would use an index to assign the returned
OutgoingHtlcResolutions into a single slice. However, this is invalid
as there are two cases where an HTLC might be skipped: if it’s an
incoming HTLC, or if the HLTC itself is dust from the PoV of the
commitment chain.
To fix this, we now instead use append to add items to the slice. This
ensure that we don’t have any “empty” items in between fully populated
items.
This commit extracts the ending dust adherence test case from the
existing TestForceClose test case into a distinct test case. With this
modification, we now ensure that the two new tests are focused and test
a single scenario at at time.
This commit fixes a bug wherein we would use the incorrect csvDelay
when crafting HTLC resolutions after a unilateral channel closure.
Previously, we would always use the csvDelay of the local party, as in
the force close case that’s the correct value. However, a unilateral
channel closure instead requires the _remote_ delay.
This commit fixes an existing bug when crafting the HTLC resolution in
the face of a commitment broadcast. Previously, we we’re using the
localKey which is incorrect, as directly below we properly use the
delayKey when crafting the secondLevelHtlcScript to sign.
This commit adds a new field: MaturityDelay, to the
UnilateralCloseSummary struct. This new field will be required, in an
upcoming update as it’s needed in order to properly sweep the
second-level HTLC outputs after MaturityDelay blocks has passed since
confirmation.
This commit fixes a minor bug (that doesn’t affect anything atm) when
crafting the SignDesc for sweeping breached outputs. Previously, we
would take the p2wkh script and then p2wsh-ify that, placing that into
the SignDesc. This is incorrect as the p2wkh script is “injected” into
the sighash when signing, and thus doesn’t need another encoding layer.
This commit adds an additional return value to SettleHTLC in order to
make way for an upcoming change to modify the way bandwidth status from
the link to the switch is reported.
This commit removes the current active LocalAvailableBalance method
from the channel state machine itself. We still maintain the internal
availableLocalBalance method locally as this is used to ensure that we
don’t add an HTLC which puts our available balance below zero.
This commit also adds an incoming flag to
HtlcRetribution struct to allow the breach arbiter to
generate the appropriate witness based on the htlc's
directionality.
It also ensures that the size of the htlc retribution
slice is now determined by the size of the number of
htlcs present in the revoked snapshot, which fixes a
minor bug that could lead to nil pointer deferences.
This commit is a follow up to the prior commit, as since we reversed
the order of the pubkeys in the multi-sig scripts, then we also need to
reverse the order of the signatures that we use when attempting to
spend the funding output directly.
When creating the script for the funding output, we were reversing the
order of the public keys due to an incorrect assertion of the return
value of the bytes.Compare function. To fix this, we now flip the
order, allowing us to properly create channels as specified within the
specification.
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 fixes an existing w.r.t the way that we constructed all
commitment transactions. We were computing the hash that the obfsucator
was derived form correctly, but we were using the first 6-bytes, rather
than the last 6 bytes.
We no longer attach the RPC client to the lnwallet logging instance as
it can generate a ton of spam in trace mode as it’ll dump the entire
hex encoded blocks, transactions, etc.
This commit fixes a bug within the HTLC construction and commitment
transaction construction that would result in HTLC _values_ within the
commitment transaction being off by a factor of 1000. This was due to
the fact that we failed to convert the amount of an HTLC, in mSAT, to
SAT before placing it as an output within the commitment transaction.
When attempt to locate the output index of a particular half, we use
the unconverted amount, meaning it was unnoticed.
This commit adds a new assertion within the TestSimpleAddSettleWorkflow
test to ensure that the HTLC is found within the commitment transaction
with the proper value in satoshi.
This commit updates the script we use to match the current
specification. The change is minor: we can say an extra byte by moving
the OP_CHECKSIG to the end of the script, and swapping the checks and
seqverify operations in the second clause. However, the witness remains
the same!
Note that this commit is temporary, and should be reverted once #231 is
merged. The reason we need to do this for now, is that we don’t
properly track the exact state of the remote party’s commitment. In
this test case, the resulting HTLC’s added are dust to one party, but
non-dust to another. So upon restart, the states (balance wise) has
diverged.
This commit fixes a lingering bug in the way the internal channel state
machine handled fee calculation. Previously, we would count the dust
HTLC’s that were trimmed towards the fee that the initiator paid. This
is invalid as otherwise, the initiator would always benefit from dust
HTLC’s. Instead, we now simply “donate” the dust HTLC’s to the miner in
the commitment transaction. This change puts us in compliance with
BOLT-0003.
This commit modifies the CommitSpendNoDelay script witness generation
function. We must modify this function as all non-delayed outputs now
also require a key derivation. The current default
signer.ComputeInputScript implementation is unable to directly look up
the public key required as it attempt to target the pub key using the
pkScript.
This commit modifies the closeObserver code to populate the signDesc in
the case we have a non-trimmed balance. Additionally, we now also add a
*wire.OutPoint field to the struct in order to allow receivers of the
message to construct a witness that can spend the newly created output
to their wallet.
This commit modifies the methods that transition the state of the
channel into an active closing state. With the new commitment design,
the delivery scripts are no longer pre-committed to the initial funding
messages. Instead, the scripts are sent at the instant that either side
decides to shutdown within the Shutdown message.
This commit adds a new companion struct: OutgoingHtlcResolution to the
commitment state machine. The purpose of this struct is the provide the
caller with the information necessary to sweep all outgoing HTLC’s in
the case of a broadcast up-to-date commitment transaction.
The HTLC resolutions allow a caller to sweep an outgoing HTLC into
their wallet after the absolute timeout of the HTLc has passed. This is
a two step process, with the first portion consisting of broadcasting
the HTLC timeout transaction itself, and the second portion consisting
of claiming the HTLC itself after a CSV delay.
This commit adds awareness of active HTLC outputs to the
BreachRetribution struct. Previously, in the case of a breach, the
struct was only populated with enough information to sweep the two
commitment outputs. With this commit, the struct now has enough
information to sweep _all_ outputs within the commitment transaction.
This commit updates the central fetchCommitmentView method to manage
and derive the necessary easy required to create new commitments due to
the new state machine design within the specification. Each state now
requires us to derive a number of keys for each commitment state:
localDelay, remoteDelay, localKey, remoteKey, the commitment point, and
finally the revocation key itself.
This commit updates the set of functions tasked with generating HTLC’s
scripts for new commitments to now adhere to the new commitment
transaction design. With this change, the process of claiming an HTLC
now requires a second-level HTLC transaction, which solves a prior
issues due to the tight coupling of the timeout and delay clauses when
claiming an HTLC.
This commit adds a new method to the commitment struct:
populateHtlcIndexes. populateHtlcIndexes modifies the set of HTLC's
locked-into the target view to have full indexing information
populated. This information is required as we need to keep track of the
indexes of each HTLC in order to properly write the current state to
disk, and also to locate the PaymentDescriptor corresponding to HTLC
outputs in the commitment transaction.
We also modify toChannelDelta to take not of these new changes, and
access the appropriate index directly.
This commit modifies the way we account for dust HTLC’s within the
commitment state machine when creating and validating new states.
Previously, an HTLC was dust if the amount of the HTLC was below the
dustLimit of the commitment chain. Now, with the HTLC covenant
transaction, the value of the HTLC also needs to cover the required fee
of the HTLC covenant transaction at the specified fee rate of the
commitment chain.
As a result, we now determine if an HTLC is dust or not, only at the
commitment site, using the new htlcIsDust function.
This commit modifies the current core channel state machine in order to
may a step towards BOLT-0002 and BOLT-0003 compliance. In this change,
we abandon the prior revocation window, in favor of a fixed revocation
window of size two. The revocation window will be filled at the start
of the lifetime of the channel, and never extended from there until the
channel has been fully closed.
We now maintain two variables, the current un-revoked commitment point,
and the next commitment point to use when creating a new state. The
next commitment point must initially be inserted into the channel state
with the InitNextRevocation method.
A major difference between the prior revocation key handling is that
the remote party now instead sends us the _commitment point_ in
isolation, which we then use locally (with our revocation base point)
to create the next full revocation key for _their_ commitment
transaction.
This commit updates much of the state interaction within the
LightningChannel structure to account for the recent changes within the
chanenldb involving the OpenChannel struct, namely the introduction of
ChannelConfig and ChannelConstraints.
This commit introduce a new struct which acts as a companion struct to
the channel state machine struct. With the new commitment state
machine, we require a signature to be signed and validated for each
outstanding non-trimmed HTLC within the commitment state. As it’s
possible to have hundreds of HTLC’s on a given commitment transaction,
rather than perform all ECDSA operations in serial, we instead aim to
parallelize the computation with a worker pool of sign+verify workers.
The two primary methods of the sigPool are SubmitVerifyBatch and
SubmitSignBatch which allow a caller to trigger an asynchronous job
execution when creating or validating a new commitment state.
This commit updates the prior set of interface-level wallet tests to
exercise the new funding workflow, and also to switch to utilizing two
wallet instances throughout the tests. This allows us to abandon the
dependency on the bobNode struct.
This commit modifies the interface-level wallet integration tests to
spin up two distinct wallet instances, wiping them after each
successful test. This change paves the way for an upcoming change which
uses two live wallet instances, rather than mocking out most of the
other interaction.
This commit removes bobNode from the wallet’s funding interaction
tests. bobNode was originally created at a very early point in lnd’s
life time before any sort of back end chain access was hooked in. At
that time the integration tests were unable to run, but bobNode allowed
us to test a portion of the funding workflow given idealized inputs.
The tests will be modified in a later commit to eschew bobNode in favor
of just having two LightningWallet instances communicate with one
another.
This commit updates the engine that drives the reservation workflow to
utilize the new ChannelConfig and ChannelConstraint structs added in
prior commits. With this change, the internal reservation engine has
been modified to retain the prior dual funder workflow, but also be
able to properly manage and execute the new single funder workflow
defined in BOLT-0002.
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.
This commit modifies the Signer interface to reflect the new key
derivation defined within BOLT-0003. This entails removing the prior
PrivateTweak field all together in favor of two new fields: SingleTweak
and DoubleTweak.
These two fields are mutually exclusive. The SingleTweak field is now
required in order to sign all regular non-delay, and also must be used
to generate signatures for the localKey, or delayKey. The DoubleTweak
field is used to generate the private key that corresponds to the
revoked revocation key.
This commit updates the constants in size.go to include the weight of
the HTLC success and timeout transactions. These values are required in
order to properly compute the fee required for a particular HTLC
transaction. The fee will change depending on if the HTLC is incoming
or outgoing.
This commit adds a series of new functions that can be used to generate
the second level HTLC transactions, and also to claim the output
created by the transaction after a delay. The details of the scripts
and transaction format can be found in BOLT #3.
This commit updates all the pkScripts used within the commitment
transaction of the party that is on the reign side of an HTLC.
The major difference in these scripts as the prior generation’s is that
the claim action is now spared into a distinct transition. This clause
is guarded by a 2-of-2 multi-sig op code, which effecting creates an
off-chain covenant forcing the party claiming the transaction to incur
a delay before the funds can be swept.
This commit updates all the spendHtlcSpend* functions which are used to
spend each of the possible clauses within the HTLC contract placed on
the sender’s commitment transaction.
This commit updates the key derivation to match the derivation required
in order to construct and validate the commitment scheme that is used
within the draft specification of the Lightning Network. The new scheme
is very similar to the prior scheme aside from the following major
differences:
* Each key (not just the revocation key) now changes with each state.
* A commitment point (a component of the revocation key) is used to
randomize each key, and also generate new tweaked versions of the key.
* Base points are used along with the commitment point to generate
the keys for the commitment transaction.
* Before the remote party would send over the fully valid revocation
key. Now the remote party sends us a commitment point, which we then
use our local revocation base point to generate their revocation key.
This commit modifies the prior revocation root generation to a newer
version which is intended to allow for easy recovery of revocation
state. Rather than using the node’s keys (which we can’t count on NOT
to change), we instead now use the block hash as a salt. With this,
given the block hash prior to the one that funded the channel, and the
node’s identity key, we can reconstruct our revocation state.
This commit adds the possibility for the initiator of a
channel to send the update_fee message, as specified
in BOLT#2. After the message is sent and both parties
have committed to the updated fee, all new commitment
messages in the channel will use the specified fee.
If an HTLC’s value is below a node’s dust limit, the amount for that
HTLC should be applied to to the fee used for the channel’s commitment
transaction.
The btclog package has been changed to defining its own logging
interface (rather than seelog's) and provides a default implementation
for callers to use.
There are two primary advantages to the new logger implementation.
First, all log messages are created before the call returns. Compared
to seelog, this prevents data races when mutable variables are logged.
Second, the new logger does not implement any kind of artifical rate
limiting (what seelog refers to as "adaptive logging"). Log messages
are outputted as soon as possible and the application will appear to
perform much better when watching standard output.
Because log rotation is not a feature of the btclog logging
implementation, it is handled by the main package by importing a file
rotation package that provides an io.Reader interface for creating
output to a rotating file output. The rotator has been configured
with the same defaults that btcd previously used in the seelog config
(10MB file limits with maximum of 3 rolls) but now compresses newly
created roll files. Due to the high compressibility of log text, the
compressed files typically reduce to around 15-30% of the original
10MB file.
This commit fixes a race condition that would at times occur in the
htlcswitch.TestChannelLinkBidirectionalOneHopPayments test case. A race
condition would occur in the goroutine running ReceiveNewCommitment
compared with the grouting that would obtain the snapshot in order to
make a forwarding decision.
We fix this by creating a new public key for each new commitment
transaction such that we complete avoid the read/write race condition.
This commit fixes a race condition that was discovered as a result of
the new htlcswitch package. The StateSnapshot method and all of the
other methods which mutate the state of the channel state machine were
using distinct mutexes. The fix is trivial: all methods accessing the
internal channel state variable now use the same mutex.
This commit fixes a bug wherein the wallet would use the default relay
fee to craft transactions. On testnet, this might be insufficient or be
rejected all together in a mainnet setting. Therefore, we now pass in
the FeeEstimator interface and ensure that it’s consulted in order to
set the relay fee the wallet will use to craft transactions.
Note that this is a hold over until we have true dynamic fee
calculation within lnd which can then be extended to the internal
wallets.
