lightning-bolts/05-onchain.md

# BOLT #5: Recommendations for On-chain Transaction Handling

## Abstract

Lightning allows for two parties (nodes A and B) to conduct transactions
off-chain by giving each of them a *cross-signed commitment transaction*, which
describes the current state of the channel (basically, the current balance).
This *commitment transaction* is updated every time a new payment is made and
is spendable at all times.

There are three ways a channel can end:

1. The good way (*mutual close*): at some point nodes A and B agree to close the
channel. They generate a *closing transaction* (which is similar to a
commitment transaction, but without any pending payments) and publish it on the
blockchain (see [BOLT #2: Channel Close](02-peer-protocol.md#channel-close)).
2. The bad way (*unilateral close*): something goes wrong, possibly without evil
intent on either side. Perhaps one party crashed, for instance. One side
publishes its *latest commitment transaction*.
3. The ugly way (*revoked transaction close*): one of the parties deliberately
tries to cheat, by publishing an *outdated commitment transaction* (presumably,
a prior version of which is more in its favor).

Because Lightning is designed to be trustless, there is no risk of loss of funds
in any of these three cases; provided that the situation is properly handled.
The goal of this document is to explain exactly how a node should react when it
encounters any of the above situations, on-chain.

# Table of Contents
  * [General Nomenclature](#general-nomenclature)
  * [Commitment Transaction](#commitment-transaction)
  * [Failing a Channel](#failing-a-channel)
  * [Mutual Close Handling](#mutual-close-handling)
  * [Unilateral Close Handling: Local Commitment Transaction](#unilateral-close-handling-local-commitment-transaction)
      * [HTLC Output Handling: Local Commitment, Local Offers](#htlc-output-handling-local-commitment-local-offers)
      * [HTLC Output Handling: Local Commitment, Remote Offers](#htlc-output-handling-local-commitment-remote-offers)
  * [Unilateral Close Handling: Remote Commitment Transaction](#unilateral-close-handling-remote-commitment-transaction)
      * [HTLC Output Handling: Remote Commitment, Local Offers](#htlc-output-handling-remote-commitment-local-offers)
      * [HTLC Output Handling: Remote Commitment, Remote Offers](#htlc-output-handling-remote-commitment-remote-offers)
  * [Revoked Transaction Close Handling](#revoked-transaction-close-handling)
	  * [Penalty Transactions Weight Calculation](#penalty-transactions-weight-calculation)
  * [General Requirements](#general-requirements)
  * [Appendix A: Expected Weights](#appendix-a-expected-weights)
	* [Expected Weight of the `to_local` Penalty Transaction Witness](#expected-weight-of-the-to-local-penalty-transaction-witness)
	* [Expected Weight of the `offered_htlc` Penalty Transaction Witness](#expected-weight-of-the-offered-htlc-penalty-transaction-witness)
	* [Expected Weight of the `accepted_htlc` Penalty Transaction Witness](#expected-weight-of-the-accepted-htlc-penalty-transaction-witness)
  * [Authors](#authors)

# General Nomenclature

Any unspent output is considered to be *unresolved* and is *resolved*
as detailed in this document. Usually this is accomplished by spending it with
another *resolving* transaction. Although, sometimes simply noting the output
for later wallet spending is sufficient, in which case the transaction containing
the output is considered to be its own *resolving* transaction.

Outputs that are *resolved* are considered *irrevocably resolved*
once the remote's *resolving* transaction is included in a block at least 100
deep, on the most-work blockchain. 100 blocks is far greater than the
longest known Bitcoin fork and is the same wait time used for
confirmations of miners' rewards (see [Reference Implementation](https://github.com/bitcoin/bitcoin/blob/4db82b7aab4ad64717f742a7318e3dc6811b41be/src/consensus/tx_verify.cpp#L223)).

## Requirements

A node:
  - once it has broadcast a funding transaction OR sent a commitment signature
  for a commitment transaction that contains an HTLC output:
    - until all outputs are *irrevocably resolved*:
      - MUST monitor the blockchain for transactions that spend any output that
      is NOT *irrevocably resolved*.
  - MUST *resolve* all outputs, as specified below.
  - MUST be prepared to resolve outputs multiple times, in case of blockchain
  reorganizations.
  - upon the funding transaction being spent, if the channel is NOT already
  closed:
    - SHOULD fail the channel.
    - MAY send a descriptive error packet.
  - SHOULD ignore invalid transactions.

## Rationale

Once a local node has some funds at stake, monitoring the blockchain is required
to ensure the remote node does not close unilaterally.

Invalid transactions (e.g. bad signatures) can be generated by anyone,
(and will be ignored by the blockchain anyway), so they should not
trigger any action.

# Commitment Transaction

Nodes A and B each hold a *commitment transaction*. Each of these commitment
transactions has four types of outputs:

1. _A's main output_: Zero or one output, to pay to *A's* commitment key.
2. _B's main output_: Zero or one output, to pay to *B's* commitment key.
3. _A's offered HTLCs_: Zero or more pending payments (*HTLCs*), to pay *B* in
return for a payment preimage.
4. _B's offered HTLCs_: Zero or more pending payments (*HTLCs*), to pay *A* in
return for a payment preimage.

To incentivize nodes A and B to cooperate, an `OP_CHECKSEQUENCEVERIFY` relative
timeout encumbers node *A's outputs* (in *A's commitment transaction*) and
node *B's outputs* (in *B's commitment transaction*). So for example, if node A
publishes its commitment transaction, it will have to wait to claim its own funds,
whereas node B will have immediate access to its own funds. As a consequence, the
two commitment transactions are not identical, but they are (usually)
symmetrical.

See [BOLT #3: Commitment Transaction](03-transactions.md#commitment-transaction)
for more details.

# Failing a Channel

Although closing a channel can be accomplished in several ways, the most
efficient is preferred.

Various error cases involve closing a channel. The requirements for sending
error messages to peers are specified in
[BOLT #1: The `error` Message](01-messaging.md#the-error-message).

## Requirements

A node:
  - if a *local commitment transaction* has NOT ever contained a `to_local`
  or HTLC output:
    - MAY simply forget the channel.
  - otherwise:
    - if the *current commitment transaction* does NOT contain `to_local` or
    other HTLC outputs:
      - MAY simply wait for the remote node to close the channel.
      - until the remote node closes:
        - MUST NOT forget the channel.
    - otherwise:
      - if it has received a valid `closing_signed` message that includes a
      sufficient fee:
        - SHOULD use this fee to perform a *mutual close*.
      - otherwise:
        - MUST use the *last commitment transaction*, for which it has a
        signature, to perform a *unilateral close*.

## Rationale

Since `dust_limit_satoshis` is supposed to prevent creation of uneconomic
outputs (which would otherwise be left forever, unspent on the blockchain), it's
insisted that all commitment transaction outputs be spent.

In the early stages of a channel, it's common for one side to have
little or no funds in the channel; in this case, having nothing at stake, a node
need not consume resources monitoring the channel state.

There exists a bias towards preferring mutual closes over unilateral closes,
because outputs of the former are unencumbered by a delay and are directly
spendable by wallets. In addition, mutual close fees tend to be less exaggerated
than those of commitment transactions. So, the only reason not to use the
signature from `closing_signed` would be if the fee offered was too small for
it to be processed.

# Mutual Close Handling

A mutual close transaction *resolves* the funding transaction output.

In the case of a mutual close, a node need not do anything else, as it has
already agreed to the output, which is sent to its specified `scriptpubkey` (see
[BOLT #2: Closing initiation: `shutdown`](02-peer-protocol.md#closing-initiation-shutdown)).

# Unilateral Close Handling: Local Commitment Transaction

This is the first of two cases involving unilateral closes. In this case, a
node discovers its *local commitment transaction*, which *resolves* the funding
transaction output.

However, a node cannot claim funds from the outputs of a unilateral close that
it initiated, until the `OP_CHECKSEQUENCEVERIFY` delay has passed (as specified
by the remote node's `to_self_delay` field). Where relevant, this situation is
noted below.

## Requirements

A node:
  - upon discovering its *local commitment transaction*:
    - SHOULD spend the `to_local` output to a convenient address.
    - MUST wait until the `OP_CHECKSEQUENCEVERIFY` delay has passed (as
    specified by the remote node's `to_self_delay` field) before spending the
    output.
      - Note: if the output is spent (as recommended), the output is *resolved*
      by the spending transaction, otherwise it is considered *resolved* by the
      commitment transaction itself.
    - MAY ignore the `to_remote` output.
      - Note: No action is required by the local node, as `to_remote` is
      considered *resolved* by the commitment transaction itself.
    - MUST handle HTLCs offered by itself as specified in
    [HTLC Output Handling: Local Commitment, Local Offers](#htlc-output-handling-local-commitment-local-offers).
    - MUST handle HTLCs offered by the remote node as
    specified in [HTLC Output Handling: Local Commitment, Remote Offers](#htlc-output-handling-local-commitment-remote-offers).

## Rationale

Spending the `to_local` output avoids having to remember the complicated
witness script, associated with that particular channel, for later
spending.

The `to_remote` output is entirely the business of the remote node, and
can be ignored.

## HTLC Output Handling: Local Commitment, Local Offers

Each HTLC output can only be spent by either a local offerer, by using the HTLC-timeout
transaction after it's timed out, or a remote recipient, if it has the payment
preimage.

There can be HTLCs which are not represented by an output: either
because they were trimmed as dust, or because the transaction has only been
partially committed.

The HTLC has *timed out* once the depth of the latest block is equal to
or greater than the HTLC `cltv_expiry`.

### Requirements

A node:
  - if the commitment transaction HTLC output is spent using the payment
  preimage, the output is considered *irrevocably resolved*:
    - MUST extract the payment preimage from the transaction input witness.
  - 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.
    - once the resolving transaction has reached reasonable depth:
      - MUST fail the corresponding incoming HTLC (if any).
      - MUST resolve the output of that HTLC-timeout transaction.
      - SHOULD resolve the HTLC-timeout transaction by spending it to a
      convenient address.
        - Note: if the output is spent (as recommended), the output is
        *resolved* by the spending transaction, otherwise it is considered
        *resolved* by the commitment transaction itself.
      - MUST wait until the `OP_CHECKSEQUENCEVERIFY` delay has passed (as
      specified by the remote node's `open_channel` `to_self_delay` field)
      before spending that HTLC-timeout output.
  - 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.

### Rationale

The payment preimage either serves to prove payment (when the offering node
originated the payment) or to redeem the corresponding incoming HTLC from
another peer (when the offering node is forwarding the payment). Once a node has
extracted the payment, it no longer cares about the fate of the HTLC-spending
transaction itself.

In cases where both resolutions are possible (e.g., when a node receives payment
success after timeout), either interpretation is acceptable; it is the
responsibility of the recipient to spend it before this occurs.

We need to use local HTLC-timeout transaction to time out the HTLC to prevent them
fulfilling it and claiming the funds, and before we can back-fail any
corresponding incoming HTLC, using `update_fail_htlc` (presumably with reason
`permanent_channel_failure`) as detailed in
[BOLT 02](https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#forwarding-htlcs).
If the incoming HTLC is on-chain too, we simply wait for it to timeout: there's
no way to signal early failure.

If an HTLC is too small to appear in *any* commitment transaction, it
can be safely failed immediately. Otherwise,
if a HTLC isn't in *local* commitment transaction a node needs to make sure
that a blockchain reorganization or race does not switch to a
commitment transaction which does contain it before the node fails it, hence
the wait. The requirement that the incoming HTLC be failed before its
own timeout still applies as an upper bound.

## HTLC Output Handling: Local Commitment, Remote Offers

Each HTLC output can only be spent by us, the recipient, using the HTLC-success
transaction, which we can only populate if we have the payment
preimage. If we don't have the preimage (and don't discover it), it's
the offerer's responsibility to spend the HTLC output once it's timed out.

There are actually several possible cases for an offered HTLC:

1. The offerer is not irrevocably committed to it. The recipient won't
   normally know the preimage here, since it won't forward HTLCs until
   they're fully committed. So using the preimage would reveal that
   this recipient is the final hop, so it's best to allow the HTLC to time out in
   this case.
2. The offerer is irrevocably committed to the offered HTLC, but the recipient hasn't yet
   committed to an outgoing HTLC. In this case the recipient can either forward
   or timeout.
3. The recipient has committed to an outgoing HTLC for the offered one. In
   this case the recipient has to use the preimage if it receives it from the
   outgoing HTLC, otherwise it will lose funds by making an outgoing
   payment without redeeming the incoming one.

### Requirements

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 using the
HTLC-success transaction, and MUST resolve the output of that
HTLC-success transaction. Otherwise, if the remote node is not
irrevocably committed to the HTLC, it MUST NOT *resolve* the output by
spending it.

A node SHOULD resolve that HTLC-success transaction output by spending
it to a convenient address. If the output is spent (as recommended),
the output is *resolved* by the spending transaction, otherwise it is
considered *resolved* by the commitment transaction itself.

A node MUST wait until the `OP_CHECKSEQUENCEVERIFY` delay has passed
(as specified by the remote node's `open_channel` `to_self_delay`
field) before spending that HTLC-success transaction output.

If not otherwise resolved, once the HTLC output has expired, it is considered
*irrevocably resolved*.

# Unilateral Close Handling: Remote Commitment Transaction

The *remote node's* commitment transaction *resolves* the funding
transaction output.

There are no delays constraining node behavior in this case, so it's simpler for
a node to handle than the case in which it discovers its local commitment
transaction.

## Requirements

When a node discovers a commitment transaction from the *remote node*:

1. `to_remote`: No action is required; this is a simple P2WPKH output to us.
   This output is considered *resolved* by the commitment transaction itself.
2. `to_local`:: No action required; this is a payment to them. This output is considered *resolved*
   by the commitment transaction.
3. HTLCs offered by the local node: See "HTLC Output Handling: Remote Commitment, Local Offers" below.
4. HTLCs offered by the remote node: See "HTLC Output Handling: Remote Commitment, Remote Offers" below.

A node MUST handle the broadcast of any *valid* commitment transaction
from the *remote node* in this way; if it is unable to do so it MUST warn
about lost funds.

## Rationale

Note that there can be more than one valid, *unrevoked* commitment
transaction after a signature has been received via `commitment_signed` and
before the corresponding `revoke_and_ack`. Either commitment can serve as
the *remote node's* commitment transaction, hence the requirement to handle both.

In the case of data loss, a node can reach a state where it doesn't
recognize all of the *remote node's* commitment transaction HTLC outputs. It can tell
this has happened because the commitment number will be greater than
expected, and because it has signed the transaction.
If both nodes support `option-data-loss-protect` the node will
know the peer's `per_commitment_point` and thus be able to derive its own
`remotekey` for the transaction and salvage its own funds (but not the
HTLCs).

## HTLC Output Handling: Remote Commitment, Local Offers

Each HTLC output can only be spent by us, the offerer, after it's timed out,
or by them, the recipient, if they have the payment preimage.

The HTLC output has *timed out* once the depth of the latest block is equal
or greater than the HTLC `cltv_expiry`.

There can be HTLCs which are not represented by an output: either
because they were trimmed as dust, or in the case where the remote node has two
*valid* commitment transactions, and the HTLCs differ in each.

### Requirements

If the commitment transaction HTLC output is spent using the payment
preimage, the output is considered *irrevocably resolved*, and the
node MUST extract the payment preimage from the HTLC-success transaction input
witness.

If the commitment transaction HTLC output has *timed out* and not
been *resolved*, the node MUST *resolve* the output by spending it
to a convenient address.

For any committed HTLC that 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.

### Rationale

If the commitment transaction is *remotes*, the only way to spend the
HTLC output using a payment preimage is for them to use the
HTLC-success transaction.

The payment preimage either serves to prove payment (when the offering node
originated the payment) or to redeem the corresponding incoming HTLC from
another peer (when the offering node is forwarding the payment). Once a node has
extracted the payment, it no longer cares about the fate of the HTLC-spending
transaction itself.

In cases where both resolutions are possible (e.g., when a node receives payment
success after timeout), either interpretation is acceptable; it is the
responsibility of the recipient to spend it before this occurs.

We need to spend the HTLC output once it has timed out to prevent
them using the HTLC-success transaction, and before we can
back-fail any corresponding incoming HTLC, using `update_fail_htlc`
(presumably with reason `permanent_channel_failure`) as detailed in
[BOLT 02](https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#forwarding-htlcs).
If the incoming HTLC is on-chain too, we simply wait for it to
timeout: there's no way to signal early failure.

If an HTLC is too small to appear in *any* commitment transaction, it
can be safely failed immediately. Otherwise,
if a HTLC isn't in the *local* commitment transaction a node needs to make sure
that a blockchain reorganization or race does not switch to a
commitment transaction which does contain it before the node fails it, hence
the wait. The requirement that the incoming HTLC be failed before its
own timeout still applies as an upper bound.

## HTLC Output Handling: Remote Commitment, Remote Offers

Each HTLC output can only be spent by us, the recipient, using the payment
preimage. If we don't have the preimage (and don't discover it), it's
the offerer's responsibility to spend the HTLC output once it's timed out.

We can only spend remote HTLC outputs if we have the payment preimage.
If we don't have the preimage (and don't discover it), it's the remote's
responsibility to spend the HTLC output once it's timed out.

There are actually several possible cases for an offered HTLC:

1. The offerer is not irrevocably committed to it. The recipient won't
   normally know the preimage here, since it won't forward HTLCs until
   they're fully committed. So using the preimage would reveal that
   this recipient is the final hop, so it's best to allow the HTLC to time out in
   this case.
2. The offerer is irrevocably committed to the offered HTLC, but the recipient hasn't yet
   committed to an outgoing HTLC. In this case the recipient can either forward
   or timeout.
3. The recipient has committed to an outgoing HTLC for the offered one. In
   this case the recipient has to use the preimage if it receives it from the
   outgoing HTLC, otherwise it will lose funds by making an outgoing
   payment without redeeming the incoming one.

### Requirements

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 to a
convenient address. Otherwise, if the remote node is not irrevocably
committed to the HTLC, it MUST NOT *resolve* the output by spending
it.

If not otherwise resolved, once the HTLC output has expired, it is considered
*irrevocably resolved*.

# Revoked Transaction Close Handling

If a node tries to broadcast old state, the remote node can use the revocation key
to claim all the funds.

## Requirements

A node MUST NOT broadcast a commitment transaction for which *it* has
exposed the revocation key.

If a node discovers a commitment transaction for which *it* has a
revocation key, that *resolves* the funding transaction output.

A node MUST resolve all unresolved outputs as follows:

1. _A's main output_: No action is required; this is a simple P2WPKH output.
   This output is considered *resolved* by the commitment transaction.
2. _B's main output_: The node MUST *resolve* this by spending using the
   revocation key.
3. _A's offered HTLCs_: The node MUST *resolve* these in one of three ways:
  * spending using the payment revocation
  * spending using any transaction once the HTLC timeout has passed
  * by noting *B's HTLC-success transaction* if B publishes it
4. _B's offered HTLCs_: The node MUST *resolve* these in one of three ways:
  * spending using the payment revocation
  * spending using the payment preimage if known
  * by noting *B's HTLC-timeout transaction* if B publishes it
5. _B's HTLC-timeout transaction_: The node MUST *resolve* this by
   spending using the revocation key.
6. _B's HTLC-success transaction_: The node MUST *resolve* this by
   spending using the revocation key. The node SHOULD extract
   the payment preimage from the transaction input witness if not
   already known.

The node MAY use a single transaction to *resolve* all the outputs, but MUST
handle its transactions being invalidated by HTLC transactions.

## Rationale

A single transaction that resolves all the outputs will be under the
standard size limit thanks to the 483 HTLC-per-party limit (see
[BOLT #2](02-peer-protocol.md#the-open_channel-message)).

Note that if a single transaction is used it may be invalidated as node B
broadcasts HTLC-timeout and HTLC-success transactions, but the
requirement of persistence, until all outputs are irrevocably resolved,
should cover this. [FIXME: May have to divide and conquer here, since they may
be able to delay us long enough to avoid successful penalty spend? ]

## Penalty Transactions Weight Calculation

There are three different scripts for penalty transactions, with the following
witnesses weight (details of the computation are in
[Appendix A](#appendix-a-expected-weights)):

    to_local_penalty_witness: 160 bytes
    offered_htlc_penalty_witness: 243 bytes
    accepted_htlc_penalty_witness: 249 bytes

The penalty txinput itself takes 41 bytes, which has a weight of 164, making the
weight of each input:

    to_local_penalty_input_weight: 324 bytes
    offered_htlc_penalty_input_weight: 407 bytes
    accepted_htlc_penalty_input_weight: 413 bytes

The rest of the penalty transaction takes 4+1+1+8+1+34+4=53 bytes of non-witness
data, assuming that it has a pay-to-witness-script-hash (the largest standard output
script), in addition to a 2-byte witness header.

In addition to outputs being swept under as penalty, the node MAY also sweep the
`to_remote` output of the commitment transaction (e.g. to reduce the total
amount paid in fees). Doing so requires the inclusion of a p2wpkh witness and
additional txinput, resulting in an additional 108 + 164 = 272 bytes.

In a worst case scenario, a node holds only incoming HTLCs, and the HTLC-timeout
transactions are not published, which forces the node to spend from the commitment
transaction.

With a maximum standard weight of 400000, the maximum number of HTLCs that can
be swept in a single transaction:

    max_num_htlcs = (400000 - 324 - 272 - (4 * 53) - 2) / 413 = 966

This allows 483 HTLCs in each direction (with both `to_local` and
`to_remote` outputs) to still be resolved in a single penalty transaction.
Note that even if the `to_remote` output is not swept, the resulting
`max_num_htlcs` is 967, which yields the same unidirectional limit of 483 HTLCs.

# General Requirements

A node SHOULD report an error to the operator if it discovers a transaction
spend the funding transaction output which does not fall into one of
these categories (mutual close, unilateral close, or revoked
transaction close). Such a transaction implies its private key has
leaked, and funds may be lost.

A node MAY simply watch the contents of the most-work chain for
transactions, or MAY watch for (valid) broadcast transactions a.k.a
mempool. Considering mempool transactions should cause lower latency
for HTLC redemption, but on-chain HTLCs should be such an unusual case
that speed cannot be considered critical.

# Appendix A: Expected Weights

## Expected Weight of the `to_local` Penalty Transaction Witness

As described in [BOLT #3](03-transactions.md), the witness for
this transaction is:

    <sig> 1 { OP_IF <key> OP_ELSE to_self_delay OP_CSV OP_DROP <key> OP_ENDIF OP_CHECKSIG }

The *expected weight* is calculated as follows:

    to_local_script: 83 bytes
        - OP_IF: 1 byte
            - OP_DATA: 1 byte (revocationkey length)
            - revocationkey: 33 bytes
            - OP_CHECKSIG: 1 byte
        - OP_ELSE: 1 byte
            - OP_DATA: 1 byte (localkey length)
            - localkey: 33 bytes
            - OP_CHECKSIG_VERIFY: 1 byte
            - OP_DATA: 1 byte (delay length)
            - delay: 8 bytes
            - OP_CHECKSEQUENCEVERIFY: 1 byte
        - OP_ENDIF: 1 byte

    to_local_penalty_witness: 160 bytes
        - number_of_witness_elements: 1 byte
        - revocation_sig_length: 1 byte
        - revocation_sig: 73 bytes
        - one_length: 1 byte
        - witness_script_length: 1 byte
        - witness_script (to_local_script)

## Expected Weight of the `offered_htlc` Penalty Transaction Witness

The *expected weight* is calculated as follows (some calculations have already
been made in [BOLT #3](03-transactions.md)):

    offered_htlc_script: 133 bytes

    offered_htlc_penalty_witness: 243 bytes
        - number_of_witness_elements: 1 byte
        - revocation_sig_length: 1 byte
        - revocation_sig: 73 bytes
        - revocation_key_length: 1 byte
        - revocation_key: 33 bytes
        - witness_script_length: 1 byte
        - witness_script (offered_htlc_script)

## Expected Weight of the `accepted_htlc` Penalty Transaction Witness

The *expected weight* is calculated as follows (some calculations have already
been made in [BOLT #3](03-transactions.md)):

    accepted_htlc_script: 139 bytes

    accepted_htlc_penalty_witness: 249 bytes
        - number_of_witness_elements: 1 byte
        - revocation_sig_length: 1 byte
        - revocation_sig: 73 bytes
        - revocation_key_length: 1 byte
        - revocation_key: 33 bytes
        - witness_script_length: 1 byte
        - witness_script (accepted_htlc_script)

# Authors

[FIXME:]

![Creative Commons License](https://i.creativecommons.org/l/by/4.0/88x31.png "License CC-BY")
<br>
This work is licensed under a [Creative Commons Attribution 4.0 International License](http://creativecommons.org/licenses/by/4.0/).