mirrors/core-lightning
1
0
Fork 0
mirror of https://github.com/ElementsProject/lightning.git synced 2024-11-19 09:54:16 +01:00
Code Issues Projects Releases Wiki Activity

lightningd: fix up BOLT references.

Browse Source 
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit is contained in:
Rusty Russell 2018-06-17 19:43:44 +09:30 committed by Christian Decker
parent ce4eef6943
commit e549bc6ecf
10 changed files with 185 additions and 147 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
lightningd/channel_control.c
View File

@ -75,8 +75,6 @@ static void peer_got_shutdown(struct channel *channel, const u8 *msg)
channel->remote_shutdown_scriptpubkey = scriptpubkey;
/* BOLT #2:
*
* A sending node MUST set `scriptpubkey` to one of the following forms:
*
* 1. `OP_DUP` `OP_HASH160` `20` 20-bytes `OP_EQUALVERIFY` `OP_CHECKSIG`
* (pay to pubkey hash), OR
@ -84,8 +82,11 @@ static void peer_got_shutdown(struct channel *channel, const u8 *msg)
* 3. `OP_0` `20` 20-bytes (version 0 pay to witness pubkey), OR
* 4. `OP_0` `32` 32-bytes (version 0 pay to witness script hash)
*
* A receiving node SHOULD fail the connection if the `scriptpubkey`
* is not one of those forms. */
* A receiving node:
*...
* - if the `scriptpubkey` is not in one of the above forms:
* - SHOULD fail the connection.
*/
if (!is_p2pkh(scriptpubkey, NULL) && !is_p2sh(scriptpubkey, NULL)
&& !is_p2wpkh(scriptpubkey, NULL) && !is_p2wsh(scriptpubkey, NULL)) {
channel_fail_permanent(channel, "Bad shutdown scriptpubkey %s",

11
lightningd/closing_control.c
View File

@ -159,10 +159,10 @@ void peer_start_closingd(struct channel *channel,
/* BOLT #2:
*
* A sending node MUST set `fee_satoshis` lower than or equal
* to the base fee of the final commitment transaction as
* calculated in [BOLT
* #3](03-transactions.md#fee-calculation).
* The sending node:
* - MUST set `fee_satoshis` less than or equal to the base
* fee of the final commitment transaction, as calculated in
* [BOLT #3](03-transactions.md#fee-calculation).
*/
feelimit = commit_tx_base_fee(channel->channel_info.feerate_per_kw[LOCAL],
0);
@ -181,7 +181,8 @@ void peer_start_closingd(struct channel *channel,
/* BOLT #3:
*
* The amounts for each output MUST BE rounded down to whole satoshis.
* Each node offering a signature:
* - MUST round each output down to whole satoshis.
*/
/* Convert unit */
funding_msatoshi = channel->funding_satoshi * 1000;

3
lightningd/dev_ping.c
View File

@ -68,8 +68,7 @@ static void json_dev_ping(struct command *cmd,
/* BOLT #1:
*
* 1. `type`: a 2-byte big-endian field indicating the type of message
* 2. `payload`
*...
* 2. `payload`: ...
* The size of the message is required by the transport layer to fit
* into a 2-byte unsigned int; therefore, the maximum possible size is
* 65535 bytes.

52
lightningd/onchain_control.c
View File

@ -26,12 +26,18 @@ static void onchaind_tell_fulfill(struct channel *channel)
/* BOLT #5:
*
* If the node receives (or already knows) a payment preimage
* for an unresolved HTLC output it was offered for which it
* has committed to an outgoing HTLC, it MUST *resolve* the
* output by spending it. Otherwise, if the other node is not
* irrevocably committed to the HTLC, it MUST NOT *resolve*
* the output by spending it.
* A local node:
* - if it receives (or already possesses) a payment preimage
* for an unresolved HTLC output that it has been offered AND
* for which it has committed to an outgoing HTLC:
* - MUST *resolve* the output by spending it, using the
* HTLC-success transaction.
* - MUST resolve the output of that HTLC-success transaction.
* - otherwise:
* - if the *remote node* is NOT irrevocably committed to
* the HTLC:
* - MUST NOT *resolve* the output by spending it.
*/
/* We only set preimage once it's irrevocably committed, and
@ -205,11 +211,13 @@ static void handle_missing_htlc_output(struct channel *channel, const u8 *msg)
/* BOLT #5:
*
* For any committed HTLC which does not have an output in this
* commitment transaction, the node MUST fail the corresponding
* incoming HTLC (if any) once the commitment transaction has reached
* reasonable depth, and MAY fail it sooner if no valid commitment
* transaction contains an output corresponding to the HTLC.
* - for any committed HTLC that does NOT have an output in this
* commitment transaction:
* - once the commitment transaction has reached reasonable depth:
* - MUST fail the corresponding incoming HTLC (if any).
* - if no *valid* commitment transaction contains an output
* corresponding to the HTLC.
* - MAY fail the corresponding incoming HTLC sooner.
*/
onchain_failed_our_htlc(channel, &htlc, "missing in commitment tx");
}
@ -225,10 +233,10 @@ static void handle_onchain_htlc_timeout(struct channel *channel, const u8 *msg)
/* BOLT #5:
*
* If the HTLC output has *timed out* and not been *resolved*, the node
* MUST *resolve* the output and MUST fail the corresponding incoming
* HTLC (if any) once the resolving transaction has reached reasonable
* depth.
* - if the commitment transaction HTLC output has *timed out* and
* hasn't been *resolved*:
* - MUST *resolve* the output by spending it using the HTLC-timeout
* transaction.
*/
onchain_failed_our_htlc(channel, &htlc, "timed out");
}
@ -337,11 +345,13 @@ static bool tell_if_missing(const struct channel *channel,
/* BOLT #5:
*
* For any committed HTLC which does not have an output in this
* commitment transaction, the node MUST fail the corresponding
* incoming HTLC (if any) once the commitment transaction has reached
* reasonable depth, and MAY fail it sooner if no valid commitment
* transaction contains an output corresponding to the HTLC.
* - for any committed HTLC that does NOT have an output in this
* commitment transaction:
* - once the commitment transaction has reached reasonable depth:
* - MUST fail the corresponding incoming HTLC (if any).
* - if no *valid* commitment transaction contains an output
* corresponding to the HTLC.
* - MAY fail the corresponding incoming HTLC sooner.
*/
if (hout->hstate >= RCVD_ADD_REVOCATION
&& hout->hstate < SENT_REMOVE_REVOCATION)
@ -422,7 +432,7 @@ enum watch_result onchaind_funding_spent(struct channel *channel,
&channel->channel_info.remote_per_commit,
/* BOLT #2:
* `to_self_delay` is the number of blocks
* that the other nodes to-self outputs
* that the other node's to-self outputs
* must be delayed */
/* So, these are reversed: they specify ours,
* we specify theirs. */

25
lightningd/opening_control.c
View File

@ -635,9 +635,10 @@ static void channel_config(struct lightningd *ld,
/* BOLT #2:
*
* The sender SHOULD set `dust_limit_satoshis` to a sufficient
* value to allow commitment transactions to propagate through
* the Bitcoin network.
* The sending node SHOULD:
*...
* - set `dust_limit_satoshis` to a sufficient value to allow
* commitment transactions to propagate through the Bitcoin network.
*/
ours->dust_limit_satoshis = 546;
ours->max_htlc_value_in_flight_msat = UINT64_MAX;
@ -647,16 +648,18 @@ static void channel_config(struct lightningd *ld,
/* BOLT #2:
*
* The sender SHOULD set `to_self_delay` sufficient to ensure
* the sender can irreversibly spend a commitment transaction
* output in case of misbehavior by the receiver.
* The sending node SHOULD:
* - set `to_self_delay` sufficient to ensure the sender can
* irreversibly spend a commitment transaction output, in case of
* misbehavior by the receiver.
*/
ours->to_self_delay = ld->config.locktime_blocks;
/* BOLT #2:
*
* It MUST fail the channel if `max_accepted_htlcs` is greater than
* 483.
* The receiving node MUST fail the channel if:
*...
* - `max_accepted_htlcs` is greater than 483.
*/
ours->max_accepted_htlcs = 483;
@ -716,9 +719,9 @@ u8 *peer_accept_channel(const tal_t *ctx,
/* BOLT #2:
*
* The sender SHOULD set `minimum_depth` to a number of blocks it
* considers reasonable to avoid double-spending of the funding
* transaction.
* The sender:
* - SHOULD set `minimum_depth` to a number of blocks it considers
* reasonable to avoid double-spending of the funding transaction.
*/
uc->minimum_depth = ld->config.anchor_confirms;

27
lightningd/options.c
View File

@ -239,8 +239,9 @@ static char *opt_set_rgb(const char *arg, struct lightningd *ld)
ld->rgb = tal_free(ld->rgb);
/* BOLT #7:
*
* the first byte of `rgb` is the red value, the second byte is the
* green value and the last byte is the blue value */
* - Note: the first byte of `rgb` is the red value, the second byte
* is the green value, and the last byte is the blue value.
*/
ld->rgb = tal_hexdata(ld, arg, strlen(arg));
if (!ld->rgb || tal_len(ld->rgb) != 3)
return tal_fmt(NULL, "rgb '%s' is not six hex digits", arg);
@ -256,8 +257,8 @@ static char *opt_set_alias(const char *arg, struct lightningd *ld)
*
* * [`32`:`alias`]
*...
* It MUST set `alias` to a valid UTF-8 string, with any `alias` bytes
* following equal to zero.
* - MUST set `alias` to a valid UTF-8 string, with any
* `alias` trailing-bytes equal to 0.
*/
if (strlen(arg) > 32)
return tal_fmt(NULL, "Alias '%s' is over 32 characters", arg);
@ -511,7 +512,10 @@ static const struct config testnet_config = {
.fee_per_satoshi = 10,
/* BOLT #7:
* Each node SHOULD flush outgoing announcements once every 60 seconds */
*
* - SHOULD flush outgoing gossip messages once every 60
* seconds, independently of the arrival times of the messages.
*/
.broadcast_interval = 60000,
/* Send a keepalive update at least every week, prune every twice that */
@ -548,14 +552,16 @@ static const struct config mainnet_config = {
/* BOLT #2:
*
* The `cltv_expiry_delta` for channels. `3R+2G+2S` */
* 1. the `cltv_expiry_delta` for channels, `3R+2G+2S`: if in doubt, a
* `cltv_expiry_delta` of 12 is reasonable (R=2, G=1, S=2)
*/
/* R = 2, G = 1, S = 3 */
.cltv_expiry_delta = 14,
/* BOLT #2:
*
* The minimum `cltv_expiry` we will accept for terminal payments: the
* worst case for the terminal node C lower at `2R+G+S` blocks */
* 4. the minimum `cltv_expiry` accepted for terminal payments: the
* worst case for the terminal node C is `2R+G+S` blocks */
.cltv_final = 10,
/* Send commit 10msec after receiving; almost immediately. */
@ -567,7 +573,10 @@ static const struct config mainnet_config = {
.fee_per_satoshi = 10,
/* BOLT #7:
* Each node SHOULD flush outgoing announcements once every 60 seconds */
*
* - SHOULD flush outgoing gossip messages once every 60
* seconds, independently of the arrival times of the messages.
*/
.broadcast_interval = 60000,
/* Send a keepalive update at least every week, prune every twice that */

18
lightningd/peer_control.c
View File

@ -180,9 +180,10 @@ u32 feerate_min(struct lightningd *ld)
/* BOLT #2:
*
* Given the variance in fees, and the fact that the transaction may
* be spent in the future, it's a good idea for the fee payer to keep
* a good margin, say 10x the expected fee requirement */
* Given the variance in fees, and the fact that the transaction may be
* spent in the future, it's a good idea for the fee payer to keep a good
* margin (say 5x the expected fee requirement)
*/
u32 feerate_max(struct lightningd *ld)
{
if (ld->config.ignore_fee_limits)
@ -648,9 +649,14 @@ static enum watch_result funding_lockin_cb(struct channel *channel,
/* BOLT #7:
*
* If the `open_channel` message had the `announce_channel` bit set,
* then both nodes must send the `announcement_signatures` message,
* otherwise they MUST NOT.
* A node:
* - if the `open_channel` message has the `announce_channel` bit set:
* - MUST send the `announcement_signatures` message.
* - MUST NOT send `announcement_signatures` messages until
* `funding_locked` has been sent AND the funding transaction has
* at least six confirmations.
* - otherwise:
* - MUST NOT send the `announcement_signatures` message.
*/
if (!(channel->channel_flags & CHANNEL_FLAGS_ANNOUNCE_CHANNEL))
return DELETE_WATCH;

146
lightningd/peer_htlcs.c
View File

@ -143,20 +143,21 @@ static void fail_out_htlc(struct htlc_out *hout, const char *localfail)
/* BOLT #4:
*
* * `amt_to_forward` - The amount in milli-satoshi to forward to the next
* (outgoing) hop specified within the routing information.
* * `amt_to_forward`: The amount, in millisatoshis, to forward to the next
* receiving peer specified within the routing information.
*
* This value MUST factor in the computed fee for this particular hop. When
* processing an incoming Sphinx packet along with the HTLC message it's
* encapsulated within, if the following inequality doesn't hold, then the
* HTLC should be rejected as it indicates a prior node in the path has
* deviated from the specified parameters:
* This value amount MUST include the origin node's computed _fee_ for the
* receiving peer. When processing an incoming Sphinx packet and the HTLC
* message that it is encapsulated within, if the following inequality
* doesn't hold, then the HTLC should be rejected as it would indicate that
* a prior hop has deviated from the specified parameters:
*
* incoming_htlc_amt - fee >= amt_to_forward
* incoming_htlc_amt - fee >= amt_to_forward
*
* Where `fee` is calculated according to the receiving node's advertised fee
* schema as described in [BOLT 7](https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md#htlc-fees), or 0 if this node is the
* final hop.
* Where `fee` is either calculated according to the receiving peer's
* advertised fee schema (as described in [BOLT
* #7](07-routing-gossip.md#htlc-fees)) or is 0, if the processing node is
* the final node.
*/
static bool check_amount(struct htlc_in *hin,
u64 amt_to_forward, u64 amt_in_htlc, u64 fee)
@ -171,21 +172,22 @@ static bool check_amount(struct htlc_in *hin,
/* BOLT #4:
*
* * `outgoing_cltv_value` - The CLTV value that the _outgoing_ HTLC carrying
* * `outgoing_cltv_value`: The CLTV value that the _outgoing_ HTLC carrying
* the packet should have.
*
* cltv_expiry - cltv_expiry_delta >= outgoing_cltv_value
*
* Inclusion of this field allows a node to both authenticate the information
* specified by the original sender and the parameters of the HTLC forwarded,
* and ensure the original sender is using the current `cltv_expiry_delta` value.
* If there is no next hop, `cltv_expiry_delta` is zero.
* If the values don't correspond, then the HTLC should be failed+rejected as
* this indicates the incoming node has tampered with the intended HTLC
* values, or the origin has an obsolete `cltv_expiry_delta` value.
* The node MUST be consistent in responding to an unexpected
* `outgoing_cltv_value` whether it is the final hop or not, to avoid
* leaking that information.
* Inclusion of this field allows a hop to both authenticate the
* information specified by the origin node, and the parameters of the
* HTLC forwarded, and ensure the origin node is using the current
* `cltv_expiry_delta` value. If there is no next hop,
* `cltv_expiry_delta` is 0. If the values don't correspond, then the
* HTLC should be failed and rejected, as this indicates that either a
* forwarding node has tampered with the intended HTLC values or that the
* origin node has an obsolete `cltv_expiry_delta` value. The hop MUST be
* consistent in responding to an unexpected `outgoing_cltv_value`,
* whether it is the final node or not, to avoid leaking its position in
* the route.
*/
static bool check_cltv(struct htlc_in *hin,
u32 cltv_expiry, u32 outgoing_cltv_value, u32 delta)
@ -241,13 +243,12 @@ static void handle_localpay(struct htlc_in *hin,
struct lightningd *ld = hin->key.channel->peer->ld;
/* BOLT #4:
*
* If the `amt_to_forward` is higher than `incoming_htlc_amt` of
* the HTLC at the final hop:
*
* 1. type: 19 (`final_incorrect_htlc_amount`)
* 2. data:
* * [`4`:`incoming_htlc_amt`]
*
* The amount in the HTLC doesn't match the value in the onion.
*/
if (!check_amount(hin, amt_to_forward, hin->msatoshi, 0)) {
failcode = WIRE_FINAL_INCORRECT_HTLC_AMOUNT;
@ -255,13 +256,12 @@ static void handle_localpay(struct htlc_in *hin,
}
/* BOLT #4:
*
* If the `outgoing_cltv_value` does not match the `cltv_expiry` of
* the HTLC at the final hop:
*
* 1. type: 18 (`final_incorrect_cltv_expiry`)
* 2. data:
* * [`4`:`cltv_expiry`]
* * [`4`:`cltv_expiry`]
*
* The CLTV expiry in the HTLC doesn't match the value in the onion.
*/
if (!check_cltv(hin, cltv_expiry, outgoing_cltv_value, 0)) {
failcode = WIRE_FINAL_INCORRECT_CLTV_EXPIRY;
@ -276,13 +276,17 @@ static void handle_localpay(struct htlc_in *hin,
/* BOLT #4:
*
* If the amount paid is less than the amount expected, the final node
* MUST fail the HTLC. If the amount paid is more than twice the
* amount expected, the final node SHOULD fail the HTLC. This allows
* the sender to reduce information leakage by altering the amount,
* without allowing accidental gross overpayment:
*
* 1. type: PERM|16 (`incorrect_payment_amount`)
* An _intermediate hop_ MUST NOT, but the _final node_:
*...
* - if the amount paid is less than the amount expected:
* - MUST fail the HTLC.
*...
* - if the amount paid is more than twice the amount expected:
* - SHOULD fail the HTLC.
* - SHOULD return an `incorrect_payment_amount` error.
* - Note: this allows the origin node to reduce information
* leakage by altering the amount while not allowing for
* accidental gross overpayment.
*/
if (details.msatoshi != NULL && hin->msatoshi < *details.msatoshi) {
failcode = WIRE_INCORRECT_PAYMENT_AMOUNT;
@ -294,7 +298,9 @@ static void handle_localpay(struct htlc_in *hin,
/* BOLT #4:
*
* If the `cltv_expiry` is too low, the final node MUST fail the HTLC:
* - if the `cltv_expiry` value is unreasonably near the present:
* - MUST fail the HTLC.
* - MUST return a `final_expiry_too_soon` error.
*/
if (get_block_height(ld->topology) + ld->config.cltv_final
> cltv_expiry) {
@ -444,10 +450,9 @@ static void forward_htlc(struct htlc_in *hin,
/* BOLT #7:
*
* The node creating `channel_update` SHOULD accept HTLCs which pay a
* fee equal or greater than:
*
* fee_base_msat + amount_msat * fee_proportional_millionths / 1000000
* The origin node:
* - SHOULD accept HTLCs that pay a fee equal to or greater than:
* - fee_base_msat + ( amount_msat * fee_proportional_millionths / 1000000 )
*/
if (mul_overflows_u64(amt_to_forward,
ld->config.fee_per_satoshi)) {
@ -469,9 +474,10 @@ static void forward_htlc(struct htlc_in *hin,
/* BOLT #2:
*
* A node MUST estimate a timeout deadline for each HTLC it offers. A
* node MUST NOT offer an HTLC with a timeout deadline before its
* `cltv_expiry`
* An offering node:
* - MUST estimate a timeout deadline for each HTLC it offers.
* - MUST NOT offer an HTLC with a timeout deadline before its
* `cltv_expiry`.
*/
/* In our case, G = 1, so we need to expire it one after it's expiration.
* But never offer an expired HTLC; that's dumb. */
@ -486,9 +492,8 @@ static void forward_htlc(struct htlc_in *hin,
/* BOLT #4:
*
* If the `cltv_expiry` is unreasonably far, we can also report an error:
*
* 1. type: 21 (`expiry_too_far`)
* - if the `cltv_expiry` is unreasonably far in the future:
* - return an `expiry_too_far` error.
*/
if (get_block_height(ld->topology)
+ ld->config.locktime_max < outgoing_cltv_value) {
@ -587,8 +592,8 @@ static bool peer_accepted_htlc(struct channel *channel,
#endif
/* BOLT #2:
*
* A sending node SHOULD fail to route any HTLC added after it
* sent `shutdown`. */
* - SHOULD fail to route any HTLC added after it has sent `shutdown`.
*/
if (channel->state == CHANNELD_SHUTTING_DOWN) {
*failcode = WIRE_PERMANENT_CHANNEL_FAILURE;
goto out;
@ -596,9 +601,11 @@ static bool peer_accepted_htlc(struct channel *channel,
/* BOLT #2:
*
* A node MUST estimate a fulfillment deadline for each HTLC it is
* attempting to fulfill. A node MUST fail (and not forward) an HTLC
* whose fulfillment deadline is already past
* A fulfilling node:
* - for each HTLC it is attempting to fulfill:
* - MUST estimate a fulfillment deadline.
* - MUST fail (and not forward) an HTLC whose fulfillment deadline is
* already past.
*/
/* Our deadline is half the cltv_delta we insist on, so this check is
* a subset of the cltv check done in handle_localpay and
@ -1290,8 +1297,9 @@ void peer_got_revoke(struct channel *channel, const u8 *msg)
/* BOLT #2:
*
* A receiving node MAY fail if the `per_commitment_secret` was not
* generated by the protocol in [BOLT #3]
* - if the `per_commitment_secret` was not generated by the protocol
* in [BOLT #3](03-transactions.md#per-commitment-secret-requirements):
* - MAY fail the channel.
*/
if (!wallet_shachain_add_hash(ld->wallet,
&channel->their_shachain,
@ -1491,9 +1499,9 @@ void free_htlcs(struct lightningd *ld, const struct channel *channel)
/* BOLT #2:
*
* For HTLCs we offer: the timeout deadline when we have to fail the channel
* and time it out on-chain. This is `G` blocks after the HTLC
* `cltv_expiry`; 1 block is reasonable.
* 2. the deadline for offered HTLCs: the deadline after which the channel has
* to be failed and timed out on-chain. This is `G` blocks after the HTLC's
* `cltv_expiry`: 1 block is reasonable.
*/
static u32 htlc_out_deadline(const struct htlc_out *hout)
{
@ -1502,10 +1510,10 @@ static u32 htlc_out_deadline(const struct htlc_out *hout)
/* BOLT #2:
*
* For HTLCs we accept and have a preimage: the fulfillment deadline when we
* have to fail the channel and fulfill the HTLC onchain before its
* `cltv_expiry`. This is steps 4-7 above, which means a deadline of `2R+G+S`
* blocks before `cltv_expiry`; 7 blocks is reasonable.
* 3. the deadline for received HTLCs this node has fulfilled: the deadline
* after which the channel has to be failed and the HTLC fulfilled on-chain
* before its `cltv_expiry`. See steps 4-7 above, which imply a deadline of
* `2R+G+S` blocks before `cltv_expiry`: 7 blocks is reasonable.
*/
/* We approximate this, by using half the cltv_expiry_delta (3R+2G+2S),
* rounded up. */
@ -1521,9 +1529,9 @@ void htlcs_notify_new_block(struct lightningd *ld, u32 height)
/* BOLT #2:
*
* A node ... MUST fail the channel if an HTLC which it offered is in
* either node's current commitment transaction past this timeout
* deadline.
* - if an HTLC which it offered is in either node's current
* commitment transaction, AND is past this timeout deadline:
* - MUST fail the channel.
*/
/* FIXME: use db to look this up in one go (earliest deadline per-peer) */
do {
@ -1561,10 +1569,12 @@ void htlcs_notify_new_block(struct lightningd *ld, u32 height)
/* BOLT #2:
*
* A node MUST estimate a fulfillment deadline for each HTLC it is
* attempting to fulfill. A node ... MUST fail the connection if a
* HTLC it has fulfilled is in either node's current commitment
* transaction past this fulfillment deadline.
* - for each HTLC it is attempting to fulfill:
* - MUST estimate a fulfillment deadline.
*...
* - if an HTLC it has fulfilled is in either node's current commitment
* transaction, AND is past this fulfillment deadline:
* - MUST fail the connection.
*/
do {
struct htlc_in *hin;

39
lightningd/test/run-commit_tx.c
View File

@ -45,9 +45,9 @@ static struct secret secret_from_hex(const char *hex)
len = strlen(hex);
/* BOLT #3:
*
* private keys are displayed as 32 bytes plus a trailing 1 (bitcoin's
* convention for "compressed" private keys, i.e. keys for which the
* public key is compressed)
* - Private keys are displayed as 32 bytes plus a trailing 1
* (Bitcoin's convention for "compressed" private keys, i.e. keys
* for which the public key is compressed).
*/
if (len == 66 && strends(hex, "01"))
len -= 2;
@ -469,17 +469,16 @@ int main(void)
* # Appendix C: Commitment and HTLC Transaction Test Vectors
*
* In the following:
* - we consider *local* transactions, which implies that all payments
* to *local* are delayed
* - we assume that *local* is the funder
* - private keys are displayed as 32 bytes plus a trailing 1
* (bitcoin's convention for "compressed" private keys, i.e. keys
* for which the public key is compressed)
* - *local* transactions are considered, which implies that all
* payments to *local* are delayed.
* - It's assumed that *local* is the funder.
* - Private keys are displayed as 32 bytes plus a trailing 1
* (Bitcoin's convention for "compressed" private keys, i.e. keys for
* which the public key is compressed).
* - Transaction signatures are all deterministic, using RFC6979 (using
* HMAC-SHA256).
*
* - transaction signatures are all deterministic, using
* RFC6979 (using HMAC-SHA256)
*
* We start by defining common basic parameters for each test vector:
* To start, common basic parameters for each test vector are defined:
* the HTLCs are not used for the first "simple commitment tx with no
* HTLCs" test.
*
@ -503,10 +502,10 @@ int main(void)
/* BOLT #3:
*
* <!-- We derive the test vector values as per Key Derivation, though
* it's not required for this test. They're included here for
* completeness and in case someone wants to reproduce the test
* vectors themselves:
* <!-- The test vector values are derived, as per Key Derivation,
* though it's not required for this test. They're included here
* for completeness and in case someone wants to reproduce the
* test vectors themselves:
*
* INTERNAL: remote_funding_privkey: 1552dfba4f6cf29a62a0af13c8d6981d36d0ef8d61ba10fb0fe90da7634d7e130101
* INTERNAL: local_payment_basepoint_secret: 111111111111111111111111111111111111111111111111111111111111111101
@ -519,9 +518,9 @@ int main(void)
* # From local_delayed_payment_basepoint_secret
* INTERNAL: local_delayed_payment_basepoint: 023c72addb4fdf09af94f0c94d7fe92a386a7e70cf8a1d85916386bb2535c7b1b1
* INTERNAL: local_per_commitment_point: 025f7117a78150fe2ef97db7cfc83bd57b2e2c0d0dd25eaf467a4a1c2a45ce1486
* INTERNAL: remote_secretkey: 8deba327a7cc6d638ab0eb025770400a6184afcba6713c210d8d10e199ff2fda01
* INTERNAL: remote_privkey: 8deba327a7cc6d638ab0eb025770400a6184afcba6713c210d8d10e199ff2fda01
* # From local_delayed_payment_basepoint_secret, local_per_commitment_point and local_delayed_payment_basepoint
* INTERNAL: local_delayed_secretkey: adf3464ce9c2f230fd2582fda4c6965e4993ca5524e8c9580e3df0cf226981ad01
* INTERNAL: local_delayed_privkey: adf3464ce9c2f230fd2582fda4c6965e4993ca5524e8c9580e3df0cf226981ad01
*/
local_funding_privkey.secret = secret_from_hex("30ff4956bbdd3222d44cc5e8a1261dab1e07957bdac5ae88fe3261ef321f374901");
x_remote_funding_privkey.secret = secret_from_hex("1552dfba4f6cf29a62a0af13c8d6981d36d0ef8d61ba10fb0fe90da7634d7e1301");
@ -750,7 +749,7 @@ int main(void)
/* BOLT #3:
*
* name: commitment tx with all 5 HTLCs untrimmed (minimum feerate)
* name: commitment tx with all five HTLCs untrimmed (minimum feerate)
* to_local_msat: 6988000000
* to_remote_msat: 3000000000
* local_feerate_per_kw: 0

2
lightningd/test/run-funding_tx.c
View File

@ -83,7 +83,7 @@ int main(void)
/* BOLT #3:
*
* The funding transaction is paid to the following keys:
* The funding transaction is paid to the following pubkeys:
*
* local_funding_pubkey: 023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb
* remote_funding_pubkey: 030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c1