Add tweaks proposed by @morehouse and @esneider

02-peer-protocol.md

@@ -814,7 +814,7 @@ The receiving node MUST fail the channel if:
   - `push_msat` is greater than `funding_satoshis` * 1000.
   - `to_self_delay` is unreasonably large.
   - `channel_type` includes `zero_fee_commitments` and:
-    - `max_accepted_htlcs` is greater than 283.
+    - `max_accepted_htlcs` is greater than 114.
     - `feerate_per_kw` is not `0`.
   - `channel_type` does not include `zero_fee_commitments` and:
     - `max_accepted_htlcs` is greater than 483.
@@ -2342,7 +2342,7 @@ still be under the maximum message size. It also ensures that
 a single penalty transaction can spend the entire commitment transaction,
 as calculated in [BOLT #5](05-onchain.md#penalty-transaction-weight-calculation).
 When using `zero_fee_commitments`, we further limit `max_accepted_htlcs` to
-283 because v3 transactions are limited to 10kvB, which decreases the number
+114 because v3 transactions are limited to 10kvB, which decreases the number
 of outputs the commitment transaction can have.
 
 `cltv_expiry` values equal to or greater than 500000000 would indicate a time in

03-transactions.md

@@ -106,7 +106,7 @@ Otherwise, the required minimum timeout on HTLCs is lengthened by this delay, ca
 
 The amounts for each output MUST be rounded down to whole satoshis.
 If this amount, minus the fees for the HTLC transaction, is less than the `dust_limit_satoshis` set by the owner of the commitment transaction, the output MUST NOT be produced.
-If `zero_fee_commitments` is used, this amount is added to the `shared_anchor`, otherwise it adds to on-chain fees.
+In that case, the amount is added to the `shared_anchor` if `zero_fee_commitments` is used, otherwise the amount is added to on-chain fees.
 
 #### `to_local` Output
 

05-onchain.md

@@ -100,8 +100,8 @@ delayed_pubkey.
 funding_pubkey.
 4. _remote node's anchor output_: one output paying to the *remote node's*
 funding_pubkey.
-5. _shared ephemeral anchor_: one output paying to the *local* or *remote*
+5. _shared anchor_: one output paying to the *local* or *remote* node's
-node's funding_pubkey.
+funding_pubkey.
 6. _local node's offered HTLCs_: Zero or more pending payments (*HTLCs*), to pay
 the *remote node* in return for a payment preimage.
 7. _remote node's offered HTLCs_: Zero or more pending payments (*HTLCs*), to
@@ -151,10 +151,13 @@ A node:
           - MUST broadcast the *last commitment transaction*, for which it has a
           signature, to perform a *unilateral close*.
           - MUST spend any `to_local_anchor` or `shared_anchor` output, providing sufficient fees
-          as incentive to include the commitment transaction in a block. When using `nVersion=2`,
+          as incentive to include the commitment transaction in a block. For `to_local_anchor`,
           special care must be taken when spending to a third-party, because this re-introduces
-          the vulnerability that was addressed by adding the CSV delay to the non-anchor outputs.
+          the pinning vulnerability that was addressed by adding the CSV delay to the non-anchor
-          - SHOULD use [replace-by-fee](https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki) or other mechanism on the spending transaction if it proves insufficient for timely inclusion in a block.
+          outputs.
+          - SHOULD use [replace-by-fee](https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki)
+          or other mechanism on the spending transaction if it proves insufficient for timely
+          inclusion in a block.
 
 ## Rationale
 
@@ -517,7 +520,8 @@ A local node:
   using the revocation private key.
   - SHOULD extract the payment preimage from the transaction input witness, if
   it's not already known.
-  - if `SIGHASH_SINGLE|SIGHASH_ANYONECANPAY` is used for HTLC transactions:
+  - if `SIGHASH_SINGLE|SIGHASH_ANYONECANPAY` is used for HTLC transactions
+  (i.e. `option_anchors` or `zero_fee_commitments` applies):
     - MAY use a single transaction to *resolve* all the outputs.
     - if confirmation doesn't happen before reaching `security_delay` blocks from
   expiry:
@@ -534,8 +538,9 @@ A single transaction that resolves all the outputs will be under the
 standard size limit because of the 483 HTLC-per-party limit (see
 [BOLT #2](02-peer-protocol.md#the-open_channel-message)).
 
-Note: when `SIGHASH_SINGLE|SIGHASH_ANYONECANPAY` is used for HTLC transactions,
+Note: when `SIGHASH_SINGLE|SIGHASH_ANYONECANPAY` is used for HTLC transactions
-the cheating node can pin spends of its HTLC-timeout/HTLC-success outputs.
+(i.e. `option_anchors` or `zero_fee_commitments`), the cheating node can pin
+spends of its HTLC-timeout/HTLC-success outputs.
 Using a single penalty transaction for all revoked outputs is thus unsafe as it
 could be blocked to propagate long enough for the _local node's `to_local` output_ 's
 relative locktime to expire and the cheating party escaping the penalty on this
@@ -590,9 +595,9 @@ Note: even if the `to_remote` output is not swept, the resulting
 
 # Generation of HTLC Transactions
 
-If `SIGHASH_ALL` is used for HTLC transactions, then HTLC-timeout and
+If `option_anchors` and `zero_fee_commitments` do not apply, then HTLC-timeout
-HTLC-success transactions are complete transactions with (hopefully!)
+and HTLC-success transactions are signed with `SIGHASH_ALL` and are complete
-reasonable fees and must be used directly.
+transactions with (hopefully!) reasonable fees and must be used directly.
 
 Otherwise, `SIGHASH_SINGLE|SIGHASH_ANYONECANPAY` MUST be used on the
 HTLC signatures received from the peer, as this allows HTLC transactions to be