Makes the helper methods for constructing witness script
hash and to-local outputs. This will allow watchtowers to
import and reuse this logic when sweeping 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 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 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.
In this commit, we modify the naming and comments of the routines that
create the sender/receiver HTLC scripts to denote that a set of
distinct keys are used. The scripts materially haven’t changed, but the
set of keys expected has.
This commit changes the use of SigHash flags in the spend
transactions created in scrit_utils. Instead of always
using SigHashAll for the sweep signature, we instead use
the sighash flag specified by the passed sign descriptor.
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 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 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!
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 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.
In order to be able to use the DeriveRevocationRoot in the createChannel
function inside the htlcswicth package we need to make it public.
NOTE: The original lnwallet.CreateChannel function haven't been
sufficient as far it not takes the private keys as input.
Primarily to avoid linting errors, the lnwallet.OP_CHECKSEQUENCEVERIFY
variable was removed and references to it replaced with
txscript.OP_CHECKSEQUENCEVERIFY.
This commit fixes a build issue that appears when attempting to
cross-compile binaries to a 32-bit system from a 64-bit system. The
issue was that the defined max-state hint overflows a 32-bit integer. To
fix this issue, we now proeprly specify a type of a uint64 for the typed
constant.
This commit removes all instances of the fastsha256 library and
replaces it with the sha256 library in the standard library. This
change should see a number of performance improvements as the standard
library has highly optimized assembly instructions with use vectorized
instructions as the platform supports.
In this commit the initial implementation of revocation hash
generation 'elkrem' was replaced with 'shachain' Rusty Russel
implementation which currently enshrined in the spec. This alghoritm has
the same asymptotic characteristics but has more complex scheme
to determine wish hash we can drop and what needs to be stored
in order to be able to achive full compression.
Introduce TimelockShift which is used to make sure the commitment
transaction is spendable by setting the locktime with it so that
it is larger than 500,000,000, thus interpreting it as Unix epoch
timestamp and not a block height. It is also smaller than the current
timestamp which has bit (1 << 30) set, so there is no risk of having
the commitment transaction be rejected. This way we can safely use
the lower 24 bits of the locktime field for part of the obscured
commitment transaction number.
Add tests to assert maximum state can be used. Also test
that more than one input in the commitment transaction
will fail and that having state number larger than
maxStateHint will fail.
Fix SetStateNumHint and GetStateNumHint to properly
set and get the stateNumHints using the lower 24 bits
of the locktime of the commitment transaction as the
lower 24 bits of the obfuscated state number and the
lower 24 bits of the sequence field as the higher 24
bits.
This commit fixes a slight scripting related issue as a result of
default policy in Bitcoin Core 0.13.1. With this version of Bitcoin
Core, nodes will now enforce a policy that ensures the first argument
of OP_IF is either an empty vector or a 0x01 value. Our current sent of
functions to generate the witness for the delay clause of the
commitment transaction instead uses a 0x00 value rather than an empty
byte vector.
With this commit we fix the issue by ensuring that we use an empty
vector rather an 0x00 for forcing the commitment delay script pathway.
