From e549bc6ecfdd7dbf12f3d096318d2ec548aaa0df Mon Sep 17 00:00:00 2001 From: Rusty Russell Date: Sun, 17 Jun 2018 19:43:44 +0930 Subject: [PATCH] lightningd: fix up BOLT references. Signed-off-by: Rusty Russell --- lightningd/channel_control.c | 9 +- lightningd/closing_control.c | 11 +-- lightningd/dev_ping.c | 3 +- lightningd/onchain_control.c | 52 ++++++----- lightningd/opening_control.c | 25 +++--- lightningd/options.c | 27 ++++-- lightningd/peer_control.c | 18 ++-- lightningd/peer_htlcs.c | 146 +++++++++++++++++-------------- lightningd/test/run-commit_tx.c | 39 ++++----- lightningd/test/run-funding_tx.c | 2 +- 10 files changed, 185 insertions(+), 147 deletions(-) diff --git a/lightningd/channel_control.c b/lightningd/channel_control.c index 1fe6347eb..6176687ea 100644 --- a/lightningd/channel_control.c +++ b/lightningd/channel_control.c @@ -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", diff --git a/lightningd/closing_control.c b/lightningd/closing_control.c index dc94530a7..216c518c5 100644 --- a/lightningd/closing_control.c +++ b/lightningd/closing_control.c @@ -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; diff --git a/lightningd/dev_ping.c b/lightningd/dev_ping.c index 131703fef..4d71eea13 100644 --- a/lightningd/dev_ping.c +++ b/lightningd/dev_ping.c @@ -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. diff --git a/lightningd/onchain_control.c b/lightningd/onchain_control.c index 199f44dd0..4f4beff6f 100644 --- a/lightningd/onchain_control.c +++ b/lightningd/onchain_control.c @@ -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. */ diff --git a/lightningd/opening_control.c b/lightningd/opening_control.c index 272d63112..9dd35bac4 100644 --- a/lightningd/opening_control.c +++ b/lightningd/opening_control.c @@ -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; diff --git a/lightningd/options.c b/lightningd/options.c index 4fc6e6c31..5076e779d 100644 --- a/lightningd/options.c +++ b/lightningd/options.c @@ -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 */ diff --git a/lightningd/peer_control.c b/lightningd/peer_control.c index 56d2dc616..53b45be09 100644 --- a/lightningd/peer_control.c +++ b/lightningd/peer_control.c @@ -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; diff --git a/lightningd/peer_htlcs.c b/lightningd/peer_htlcs.c index 7490d3dab..8efa0bb51 100644 --- a/lightningd/peer_htlcs.c +++ b/lightningd/peer_htlcs.c @@ -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; diff --git a/lightningd/test/run-commit_tx.c b/lightningd/test/run-commit_tx.c index c4f6f2b03..8696b58d2 100644 --- a/lightningd/test/run-commit_tx.c +++ b/lightningd/test/run-commit_tx.c @@ -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: * - *