Make it clear what kind of key we're talking about. We use the abbreviation
pubkey for public key (as it's quite common to use in field names), but
generally spell out 'private'.
(I generally prefer 'secret' to 'private' but we use private far more often
already, and we use 'secret' for things which don't directly derive keys).
Fixes: #368
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
It misrenders on GitHub. Matt had a patch which changed the actual
form of the requiremnt, this uses ``` instead.
Based-on-Patch-By: Matt Corallo @TheBlueMatt
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
In this commit, we modify the cooperative closing transaction to use
version 2. Currently eclair and lnd already use version 2, while
c-lightning uses version 1. The commitment transaction already uses
version 2, so making this additional transaction (which spends the
funding output) also use version 2 would be consistent. Additionally,
as a best practice, we should be using the highest currently
defined/use transaction version.
This is stolen from @sstone's #243 "reduce attack surface".
This breaks compatibility, as agreed at the 2017-11-13 meeting.
Note also that it does not update the test vectors.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
An 0x01 byte is appended to the end of private keys in the test
vectors to mark them as using compressed serialization to derive the
pubkeys. Two of the private keys have two 0x01 bytes appended,
presumably by accident.
The only surprise here (maybe?) is that we use the commitment number encoding.
I think that makes sense, but it was unspecified before.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit attempts to clarify some ambiguity in the way the
revocation key derivation was formerly described. Rather than framing
the description in terms of local vs remote nodes, we instead frame the
description around the _process_ of creating a new commitment
transaction for a remote node,
[ minor typos and remove weird part-sentence -- RR ]
Plus a few more missing ones, and some consistency fixes in names
as pointed out by Roasbeed and Fabrice.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
As per ElementsProject/lightning#134 Fabrice points out that to calculate
our own commitment tx, we use the *other* side's revocation basepoint:
The revocationkey is a blinded key: the remote node provides the base,
and the local node provides the blinding factor which it later
reveals
Thus, we fix the test vectors by renaming "local_revocation_basepoint"
to "remote_revocation_basepoint", which is what we should be using.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We didn't update it for 394da29189
"BOLT 3: fix test vector derivation."
This doesn't actually change any results, just fixes an intermediate
calculation.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This means more bytes if we need to create a penalty tx, but less for
normal operation:
Witness script for offered htlcs: 139 bytes -> 133 bytes.
Witness script for accepted htlcs: 156 bytes -> 139 bytes.
It's also a little simpler; it's just an OP_IF around the old scripts
to test for the revocation key being the top arg.
Suggested-by: Joseph Poon <joseph@lightning.network>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
