Fix update script &, footnotes

Author: moonsettler

bip-0442.md

@@ -63,7 +63,7 @@ OP_EQUALVERIFY                         #
 
 ### Use in Lightning Symmetry
 
-Lightning Symmetry contracts require data availability for contested closes. By forcing parties to include settlement transaction hashes in the witness, later updates can reconstruct scripts using only the latest state.
+Lightning Symmetry contracts require data availability for contested closes. [^3] By forcing parties to include settlement transaction hashes in the witness, later updates can reconstruct scripts using only the latest state.
 [^3]: The required data is a full CTV hash of the settlement transaction when there are open HTLCs, or merely the difference in balance between the channel partners in other cases. Whether the latter optimization would be used is an implementation detail not further discussed here.
 
 ```shell
@@ -73,7 +73,7 @@ Lightning Symmetry contracts require data availability for contested closes. By
 # settlement-n-hash:                   { nSequence(2w), out(A, amount(A)), out(B, amount(B)) }
 # state-n-recovery-data:               { settlement-n-hash or state-n-balance }
 ```
-#### Example channel script (pseudo-code):
+#### Example channel script (pseudo-code)
 
 ```shell
 # Witness: <sig> <state-n-recovery-data> <state-n-hash>
@@ -86,9 +86,7 @@ OP_CHECKLOCKTIMEVERIFY                 # <1>, <S+1>
 OP_DROP                                # <1>
 ```
 
-*Note: `state-n-hash` commits to a specific `nLockTime` value for the transaction through `OP_CHECKTEMPLATEVERIFY`; `OP_CHECKLOCKTIMEVERIFY` ensures that the state progression can only go forward (the transaction needs to have greater `nLockTime` value than the intermediate state being spent).*
-
-#### Channel update script (pseudo-code):
+#### Channel update script (pseudo-code) for m > n
 
 ```shell
 OP_IF
@@ -97,43 +95,45 @@ OP_IF
     OP_PAIRCOMMIT                      # <sig>, PC(state-m-recovery-data, state-m-hash)
     OP_INTERNALKEY                     # <sig>, PC(state-m-recovery-data, state-m-hash), <internal-key>
     OP_CHECKSIGFROMSTACK               # <1>
-    OP_PUSHDATA (S+1)                  # <1>, <S+1>
-    OP_CHECKLOCKTIMEVERIFY             # <1>, <S+1>
+    OP_PUSHDATA (S+n+1)                # <1>, <S+n+1>
+    OP_CHECKLOCKTIMEVERIFY             # <1>, <S+n+1>
     OP_DROP                            # <1>
 OP_ELSE
-    # Witness: <settlement-n-hash>
+    # Empty witness stack
+    OP_PUSHDATA (settlement-n-hash)    # <settlement-n-hash>
     OP_CHECKTEMPLATEVERIFY             # <settlement-n-hash>
     OP_0NOTEQUAL                       # <1>
 OP_ENDIF
 ```
 
-*Note: `OP_0NOTEQUAL` can be omitted (any non-zero value left on the stack would be accepted by the script interpreter).*
+These constructions ensure both parties sign the same pair hash, requiring inclusion of both update and settlement hashes in the witness. [^4] [^5]
 
-These constructions ensure both parties sign the same pair hash, requiring inclusion of both update and settlement hashes in the witness.
+[^4]: `state-n-hash` commits to a specific `nLockTime` value for the transaction through `OP_CHECKTEMPLATEVERIFY`; `OP_CHECKLOCKTIMEVERIFY` ensures that the state progression can only go forward (the transaction needs to have greater `nLockTime` value than the intermediate state 
+[^5]: `OP_0NOTEQUAL` can be omitted (any non-zero value left on the stack would be accepted by the script interpreter).
 
 ### In MATT
 
-The Merklize All The Things ([MATT]) framework uses `OP_CAT` to combine items for commitments. `OP_PAIRCOMMIT` provides a more ergonomic and secure alternative[^4].
+The Merklize All The Things ([MATT]) framework uses `OP_CAT` to combine items for commitments. `OP_PAIRCOMMIT` provides a more ergonomic and secure alternative[^6].
 
-[^4]: Naive use of `OP_CAT` is vulnerable to byte shifting attacks. E.g. `0x0102 || 0x03` equals `0x01 || 0x0203`. Mitigation requires length checking or hashing.
+[^6]: Naive use of `OP_CAT` is vulnerable to byte shifting attacks. E.g. `0x0102 || 0x03` equals `0x01 || 0x0203`. Mitigation requires length checking or hashing.
 
 ## Alternative approaches
 
 Alternative approaches considered and rejected:
 
-- `OP_CAT`[^4][^7]
-- SHA256 streaming opcodes[^7]
+- `OP_CAT`[^6][^9]
+- SHA256 streaming opcodes[^9]
 - Merkle operation opcodes
 - 'Kitty' CAT: `OP_CAT` with size limits
-- `OP_CHECKTEMPLATEVERIFY` committing to the taproot annex[^5]
+- `OP_CHECKTEMPLATEVERIFY` committing to the taproot annex[^7]
 - `OP_CHECKSIGFROMSTACK` on n elements
 - `OP_VECTORCOMMIT`: generalized for n > 2 elements
 - ReKey/Laddering[^2]
-- `OP_RETURN`[^6]
+- `OP_RETURN`[^8]
 
-[^5]: Committing to the taproot annex allows one additional item, but it is not accessible to script.
-[^6]: `OP_RETURN` can commit to additional data, but is costly and not accessible to script.
-[^7]: `OP_PAIRCOMMIT` enables useful scripts without the risks of `OP_CAT` (see [CAT-tricks-I], [CAT-tricks-II]).
+[^7]: Committing to the taproot annex allows one additional item, but it is not accessible to script.
+[^8]: `OP_RETURN` can commit to additional data, but is costly and not accessible to script.
+[^9]: `OP_PAIRCOMMIT` enables useful scripts without the risks of `OP_CAT` (see [CAT-tricks-I], [CAT-tricks-II]).
 
 ## Reference Implementation