Commit Graph

420 Commits

Author SHA1 Message Date
Olaoluwa Osuntokun
07b0604458
lnwallet: add TweakPubKeyWithTweak helper function
This commit adds a new helper function which is identical to
TweakPubkey, but lets the caller specify their own hash tweak.
2017-07-30 17:52:22 -07:00
Olaoluwa Osuntokun
899fa1ea3e
lnwallet: properly populate the signDesc within UnilateralCloseSummary
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.
2017-07-30 17:52:18 -07:00
Olaoluwa Osuntokun
8a23de5303
lnwallet: consult current state instead of revocation log during unilateral closure 2017-07-30 17:52:14 -07:00
Olaoluwa Osuntokun
6ad9d218b0
lnwallet: update all channel unittests due to new commitment design 2017-07-30 17:51:09 -07:00
Olaoluwa Osuntokun
8121bc77ce
lnwallet: add delivery scripts as a param to CreateCloseProposal+ CompleteCooperativeClose
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.
2017-07-30 17:51:05 -07:00
Olaoluwa Osuntokun
40e9120c04
lnwallet: populate HTLC resolutions after observing a unilateral channel close 2017-07-30 17:51:02 -07:00
Olaoluwa Osuntokun
01aa4eb2ae
lnwallet: populate HTLC resolutions within the ForceCloseSummary 2017-07-30 17:50:59 -07:00
Olaoluwa Osuntokun
83e0116d7e
lnwallet: extend the UnilateralCloseSummary to include HTLC resolutions
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.
2017-07-30 17:50:55 -07:00
Olaoluwa Osuntokun
a4c07d061e
lnwallet: the BreachRetribution struct is now aware of HTLC outputs
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.
2017-07-30 17:50:51 -07:00
Olaoluwa Osuntokun
5a78f80ffe
lnwallet: update restoreStateLogs to be aware of new commitment scheme 2017-07-30 17:50:47 -07:00
Olaoluwa Osuntokun
b9da43a2b8
lnwallet: update fetchCommitmentView due to new commitment design
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.
2017-07-30 17:50:43 -07:00
Olaoluwa Osuntokun
3a052d2874
lnwallet: when creating new states, dispatch HTLC signing to sigPool 2017-07-30 17:50:40 -07:00
Olaoluwa Osuntokun
f569b80a80
lnwallet: when verifying new states, dispatch HTLC sig validation to sigPool 2017-07-30 17:50:37 -07:00
Olaoluwa Osuntokun
cd8672f824
lnwallet: update CreateCommitTx due to new key derivation 2017-07-30 17:50:34 -07:00
Olaoluwa Osuntokun
e314b83559
lnwallet: update HTLC script generation to account for new covenant HTLC's
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.
2017-07-30 17:50:31 -07:00
Olaoluwa Osuntokun
8b9a58cb15
lnwallet: add a sigPool instances to the state machine struct 2017-07-30 17:50:27 -07:00
Olaoluwa Osuntokun
4c9bd9dc54
lnwallet: when handling possible channel breach, only log if contract breach 2017-07-30 17:50:24 -07:00
Olaoluwa Osuntokun
e56258917e
lnwallet: introduce populateHtlcIndexes for tracking HTLC indexes in commitments
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.
2017-07-30 17:50:21 -07:00
Olaoluwa Osuntokun
549688d793
lnwallet: remove isDustLocal and isDustRemote, replace w/ htlcIsDust
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.
2017-07-30 17:50:16 -07:00
Olaoluwa Osuntokun
91165d98bb
lnwallet: eliminate the InitialRevocationWindow within the state machine
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.
2017-07-30 17:50:13 -07:00
Olaoluwa Osuntokun
c7df82ab68
lnwallet: update the LightningChannel API usage for recent channels changes
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.
2017-07-30 17:50:10 -07:00
Olaoluwa Osuntokun
b5044e9217
lnwallet: introduce the sigPool struct to optimize state creation+verification
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.
2017-07-30 17:50:06 -07:00
Olaoluwa Osuntokun
30b1cbc1fd
lnwallet: update interface-level wallet tests for new funding flow
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.
2017-07-30 17:50:03 -07:00
Olaoluwa Osuntokun
5dc0b407f3
lnwallet: update the btcwallet Signer interface due to new key derivation 2017-07-30 17:50:00 -07:00
Olaoluwa Osuntokun
c872d94606
lnwallet: convert interface-level tests to spin up two wallet instances
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.
2017-07-30 17:49:57 -07:00
Olaoluwa Osuntokun
4f02a2af80
lnwallet: remove bobNode as sadly he's no longer needed
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.
2017-07-30 17:49:54 -07:00
Olaoluwa Osuntokun
eca8dd1076
lnwallet: update testSignOutputUsingTweaks to exercise new key derivation 2017-07-30 17:49:50 -07:00
Olaoluwa Osuntokun
9edc335049
lnwallet: update internal funding workflow to account for BOLT-0002
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.
2017-07-30 17:49:47 -07:00
Olaoluwa Osuntokun
441e5b2d7c
lnwallet: add new helper function to generate both comitment pairs 2017-07-30 17:49:44 -07:00
Olaoluwa Osuntokun
62110b33e7
lnwallet: flesh out the Config struct, wallet constructor now takes 2017-07-30 17:49:41 -07:00
Olaoluwa Osuntokun
c63c7cd22f
lnwallet: update Channel[Reservation+Contribution] for new funding flow
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.
2017-07-30 17:49:37 -07:00
Olaoluwa Osuntokun
e930af4b43
lnwallet: convert interface-level tests to be run as sub-tests 2017-07-30 17:49:34 -07:00
Olaoluwa Osuntokun
9c0261206d
lnwallet: modify the Signer interface to reflect new key derivation scheme
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.
2017-07-30 17:49:31 -07:00
Olaoluwa Osuntokun
7b002175f4
lnwallet: update state hint derivation to match BOLT-0003 2017-07-30 17:49:28 -07:00
Olaoluwa Osuntokun
ca45ae7524
lnwallet: update TestCommitmentSpendValidation due to new commitment scripts 2017-07-30 17:49:25 -07:00
Olaoluwa Osuntokun
016f56e8e3
lnwallet: update TestRevocationKeyDerivation to use new derivation 2017-07-30 17:49:22 -07:00
Olaoluwa Osuntokun
44ffcf2156
lnwallet: add new test case to exercise singly tweaked key derivation 2017-07-30 17:49:19 -07:00
Olaoluwa Osuntokun
5b6cc5e92d
lnwallet: TestHTLCSenderSpendValidation for new HTLC scripts 2017-07-30 17:49:16 -07:00
Olaoluwa Osuntokun
7c035a4729
lnwallet: update TestHTLCSenderSpendValidation for new scripts 2017-07-30 17:49:13 -07:00
Olaoluwa Osuntokun
c4866723d1
lnwallet: add redemption+spend tests for the second-level HTLC txns 2017-07-30 17:49:09 -07:00
Olaoluwa Osuntokun
1a9ada4897
lnwallet: move stateHintTests global var into TestCommitTxStateHint 2017-07-30 17:49:06 -07:00
Olaoluwa Osuntokun
4e4375513d
lnwallet: update MaxHTLCNumber to precisely match the spec 2017-07-30 17:49:03 -07:00
Olaoluwa Osuntokun
71e47283cf
lnwallet: update size.go to add the weight of the success+timeout txns
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.
2017-07-30 17:49:00 -07:00
Olaoluwa Osuntokun
360876944e
lnwallet: add new functions to generate + claim second-level HTLC txns
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.
2017-07-30 17:48:56 -07:00
Olaoluwa Osuntokun
f70697bf71
lnwallet: update all witness gen funcs for receiver's HTLC scripts 2017-07-30 17:48:53 -07:00
Olaoluwa Osuntokun
4b1a7091e6
lnwallet: update public key scripts for the HTLC receiver's outputs
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.
2017-07-30 17:48:50 -07:00
Olaoluwa Osuntokun
d697c6ca9a
lnwallet: update the witness generation funcs for sender's HTLC output
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.
2017-07-30 17:48:47 -07:00
Olaoluwa Osuntokun
8f5129e08f
lnwallet: update public key scripts for the HTLC sender's commitment tx 2017-07-30 17:48:44 -07:00
Olaoluwa Osuntokun
0b9c117bbd
lnwallet: update key derivation for the commitment txn scheme
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.
2017-07-30 17:48:41 -07:00
Olaoluwa Osuntokun
13404243cf
lnwallet: revocation root generation is now based on a block hash + node 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.
2017-07-30 17:48:38 -07:00