<p>The maximum standard weight is a restriction on bitcoin transaction size. It's the maximum weight that a transaction can have to be 'standard', which means it is still relayed by unmodified bitcoin core nodes. You could have a bigger tx in a block, but you would probably have to find a miner yourself that is willing to include it. </p>

<p>The concept of weight is important here, it's the new way of measuring transaction size since segwit and is thoroughly described <a href="https://en.bitcoin.it/wiki/Weight_units" rel="nofollow noreferrer">here</a></p>

<p>Aside from that, what exactly don't you understand in the calculation?</p>

CC BY-SA 4.0
2020-03-12T00:18:03.043Z
Oh I don't understand how calculation of `max_num_htlcs` turns into 966. What does `(400000 - 324 - 272 - (4 * 53) - 2) / 413` mean?
Guillaez
CC BY-SA 4.0
2020-03-13T09:07:45.407Z
I think you need to try a little harder. Please take the time to try to understand the text that you linked to. They tried to explain what they did there. Now it may be that you don't understand every part of what they are trying to explain. That's fine. Then you can ask a specific question. But just asking people to write an even more elaborate text in case you might take the time to read it this time seem a little lazy to me.
stefanwouldgo
CC BY-SA 4.0
2020-03-11T10:13:59.963Z
2020-03-11T10:13:59.963Z
stefanwouldgo
<p>The rationale is given <a href="https://github.com/lightning/bolts/blob/08ce2f6f83619b777bebd86d6dff4a29096e35ae/02-peer-protocol.md#rationale-21" rel="nofollow noreferrer">in BOLT #2</a>:</p>
<blockquote>
<p><code>max_accepted_htlcs</code> is limited to 483 to ensure that, even if both sides send the maximum number of HTLCs, the <code>commitment_signed</code> message will still be under the <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/08-transport.md#lightning-message-specification" rel="nofollow noreferrer">maximum message size</a>. It also ensures that a single penalty transaction can spend the entire commitment transaction, as calculated in <a href="https://github.com/lightning/bolts/blob/08ce2f6f83619b777bebd86d6dff4a29096e35ae/05-onchain.md#penalty-transaction-weight-calculation" rel="nofollow noreferrer">BOLT #5</a>.</p>
</blockquote>
<p>The maximum message size is set in <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/08-transport.md#lightning-message-specification" rel="nofollow noreferrer">BOLT #8</a> to about 65kB. Therefore it is necessary to limit the size of a commitment transaction, which is otherwise bounded by the block size (4M Weight Units) according to consensus and the maximum standard transaction size (400k Weight Units) according to relay policy.</p>
<p>The second part of the rationale is maybe less clear. An outgoing HTLC in your channel adds an output to each of the two commitment transactions. Same for an incoming HTLC. The limit therefore makes it so there is at most 966 HTLC outputs in a single transaction.</p>
<p>The calculation in <a href="https://github.com/lightning/bolts/blob/08ce2f6f83619b777bebd86d6dff4a29096e35ae/05-onchain.md#penalty-transaction-weight-calculation" rel="nofollow noreferrer">BOLT #5</a> to justify this choice is the following:</p>
<pre><code>max_num_htlcs = (400000 - 324 - 272 - (4 * 53) - 2) / 413 = 966
</code></pre>
<p>Here is what each of the number corresponds to:</p>
<ul>
<li>400'000: the maximum standard transaction weight</li>
<li>324: the weight of the input spending the output in the commitment transaction paying yourself.</li>
<li>272: the weight of the input spending the output in the commitment transaction paying your peer.</li>
<li>53: the size of the header and the outputs of the penalty transaction. Multiplied by 4 because it is not witness data.</li>
<li>2 : the size of the witness header.</li>
<li>413 : the maximum weight to spend an HTLC output.</li>
</ul>

CC BY-SA 4.0
2020-03-20T10:48:21.577Z
Great explanation, except that it's 400,000 WU, not 4,000,000, because it's limited by transaction standardness, not block size (see my answer above).
stefanwouldgo
CC BY-SA 4.0
2020-03-21T10:09:25.830Z
Thanks Stephan, will amend !
Antoine Poinsot
CC BY-SA 4.0
2024-04-02T11:54:34.453Z
@AntoinePoinsot: I don’t understand why an HTLC would add _two_ new outputs to the commitment transaction. Wouldn’t it just be one that can be spent in two different ways?
Murch
CC BY-SA 4.0
2024-04-02T12:35:42.070Z
@Murch yeah there is multiple things wrong with this answser. I'm not sure where this 2-outputs per HTLC comes from, and some links are incorrect. I'm trying to understand what my 4-years-ago self meant now.
Antoine Poinsot
CC BY-SA 4.0
2024-04-02T13:57:46.057Z
Aaah alright. Just understood what i meant! It's maximum 483 htlcs accepted by each side! So it's 2 outputs added per bi-directional HTLC per commitment transaction. Maybe i was also confused, but maybe it was just english lacking even more back then. Making an edit now.
Antoine Poinsot
CC BY-SA 4.0
2020-03-13T16:24:44.580Z
2024-04-02T16:50:01.063Z
2024-04-02T16:50:01.063Z
Antoine Poinsot
<p>The maximum acceptable <code>max_accepted_htlcs</code> (maximum number of HTLCs forwarded concurrently) is specified by the <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#rationale-7" rel="nofollow noreferrer">BOLTS</a> as being <code>483</code>.</p>
<p>How was this value chosen ?</p>

<lightning-network><lightning-network-daemon><lightning-rfc>
Lightning Network: How was the maximum allowed HTLCs in flight computed?
Guillaez
# Lightning Network: How was the maximum allowed HTLCs in flight computed?

(Asked by: username_0 on 2020-03-10)

The maximum acceptable `max_accepted_htlcs` (maximum number of HTLCs forwarded concurrently) is specified by the [BOLTS](https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#rationale-7) as being `483`.

How was this value chosen ?

**Tags:** lightning-network, lightning-network-daemon, lightning-rfc


---

## 2 answers

### Answer by username_2 on 2020-03-13. Score: 4 | Accepted answer

The rationale is given [in BOLT #2](https://github.com/lightning/bolts/blob/08ce2f6f83619b777bebd86d6dff4a29096e35ae/02-peer-protocol.md#rationale-21):

> `max_accepted_htlcs` is limited to 483 to ensure that, even if both sides send the maximum number of HTLCs, the `commitment_signed` message will still be under the [maximum message size](https://github.com/lightningnetwork/lightning-rfc/blob/master/08-transport.md#lightning-message-specification). It also ensures that a single penalty transaction can spend the entire commitment transaction, as calculated in [BOLT #5](https://github.com/lightning/bolts/blob/08ce2f6f83619b777bebd86d6dff4a29096e35ae/05-onchain.md#penalty-transaction-weight-calculation).

The maximum message size is set in [BOLT #8](https://github.com/lightningnetwork/lightning-rfc/blob/master/08-transport.md#lightning-message-specification) to about 65kB. Therefore it is necessary to limit the size of a commitment transaction, which is otherwise bounded by the block size (4M Weight Units) according to consensus and the maximum standard transaction size (400k Weight Units) according to relay policy.

The second part of the rationale is maybe less clear. An outgoing HTLC in your channel adds an output to each of the two commitment transactions. Same for an incoming HTLC. The limit therefore makes it so there is at most 966 HTLC outputs in a single transaction.

The calculation in [BOLT #5](https://github.com/lightning/bolts/blob/08ce2f6f83619b777bebd86d6dff4a29096e35ae/05-onchain.md#penalty-transaction-weight-calculation) to justify this choice is the following:

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

```

Here is what each of the number corresponds to:

* 400'000: the maximum standard transaction weight
* 324: the weight of the input spending the output in the commitment transaction paying yourself.
* 272: the weight of the input spending the output in the commitment transaction paying your peer.
* 53: the size of the header and the outputs of the penalty transaction. Multiplied by 4 because it is not witness data.
* 2 : the size of the witness header.
* 413 : the maximum weight to spend an HTLC output.

> **Comments:**
> **username_1**: Great explanation, except that it's 400,000 WU, not 4,000,000, because it's limited by transaction standardness, not block size (see my answer above).  
> **username_2**: Thanks Stephan, will amend !  
> **username_3**: @username_2: I don’t understand why an HTLC would add _two_ new outputs to the commitment transaction. Wouldn’t it just be one that can be spent in two different ways?  
> **username_2**: @username_3 yeah there is multiple things wrong with this answser. I'm not sure where this 2-outputs per HTLC comes from, and some links are incorrect. I'm trying to understand what my 4-years-ago self meant now.  
> **username_2**: Aaah alright. Just understood what i meant! It's maximum 483 htlcs accepted by each side! So it's 2 outputs added per bi-directional HTLC per commitment transaction. Maybe i was also confused, but maybe it was just english lacking even more back then. Making an edit now.  

---

### Answer by username_1 on 2020-03-11. Score: 0

The maximum standard weight is a restriction on bitcoin transaction size. It's the maximum weight that a transaction can have to be 'standard', which means it is still relayed by unmodified bitcoin core nodes. You could have a bigger tx in a block, but you would probably have to find a miner yourself that is willing to include it.

The concept of weight is important here, it's the new way of measuring transaction size since segwit and is thoroughly described [here](https://en.bitcoin.it/wiki/Weight_units)

Aside from that, what exactly don't you understand in the calculation?

> **Comments:**
> **username_0**: Oh I don't understand how calculation of `max_num_htlcs` turns into 966. What does `(400000 - 324 - 272 - (4 * 53) - 2) / 413` mean?  
> **username_1**: I think you need to try a little harder. Please take the time to try to understand the text that you linked to. They tried to explain what they did there. Now it may be that you don't understand every part of what they are trying to explain. That's fine. Then you can ask a specific question. But just asking people to write an even more elaborate text in case you might take the time to read it this time seem a little lazy to me.  

---

