Update Motivation section, further carifications

bip-0442.md

@@ -17,24 +17,21 @@ provides limited vector commitment functionality in tapscript.
 
 When evaluated, the `OP_PAIRCOMMIT` instruction:
 * Pops the top two values off the stack,
-* takes the "PairCommit" tagged SHA256 hash of the stack elements,
-* pushes the resulting commitment on the top of the stack.
+* takes the "PairCommit" tagged SHA256 hash of the stack elements with size
+committments,
+* pushes the resulting 32-byte hash to the top of stack.
 
 ## Motivation
 
-To do [LN-Symmetry] contracts that don't require the nodes to keep old states,
-we need to solve the data availability problem presented by unilateral closes.
-Channel peers must be able to reconstruct the script that spends an
-intermediate state.
+Currently bitcoin lacks a way to hash multiple stack elements together. Which
+means building Merkle trees or verifying inclusion in a tree is not supported.
 
-Using in sequence `OP_CHECKTEMPLATEVERIFY`, `OP_PAIRCOMMIT`, `OP_INTERNALKEY`
-and `OP_CHECKSIGFROMSTACK` we can construct a [rebindable channel] that is also
-[optimal].
+`OP_PAIRCOMMIT` is a simple and efficient tool to commit to two stack elements,
+in a way that makes length redistirubtion attacks infeasible.
 
-The number of SHA256 iterations is minimized in the primary use case we
-can optimize for, which is LN-Symmetry. Since the Tag can be pre-computed as
-mid-state, it would only take 1 or 2 hash cycles in validation for the
-unilateral close scenario.
+The number of SHA256 iterations is minimized in the typical use cases we can
+optimize for. Since the Tag can be pre-computed as mid-state, it would only
+take 1 or 2 hash cycles in validation for the unilateral close scenario.
 
 ## Specification
 
@@ -95,6 +92,15 @@ highly optimized for just 2 stack elements.
 
 ### Use in LN-Symmetry
 
+To do [LN-Symmetry] contracts that don't require the nodes to keep old states,
+we need to solve the data availability problem presented by unilateral closes.
+Channel peers must be able to reconstruct the script that spends an
+intermediate state.
+
+Using in sequence `OP_CHECKTEMPLATEVERIFY`, `OP_PAIRCOMMIT`, `OP_INTERNALKEY`
+and `OP_CHECKSIGFROMSTACK` we can construct a [rebindable channel] that is also
+[optimal].
+
 The following assembly-like pseudo-code shows a possible LN-Symmetry channel
 construction that provides data availability to spend to the latest state from
 an earlier state pushed on-chain with a forced close by channel partner.
@@ -137,8 +143,13 @@ https://github.com/lnhance/bitcoin/pull/6/files
 If `OP_CAT` was available, it could be used to combine multiple stack elements
 that get verified with `OP_CHECKSIGFROMSTACK` as a valid state update.
 
+Using `OP_CAT` for this purpose requires additional opcodes to prevent witness
+malleability (e.g. `0x0102 0x03 OP_CAT` is identical to `0x01 0x0203 OP_CAT`).
+
 `OP_PAIRCOMMIT` solves this specific problem without introducing a wide range
-of potentially controversial new behaviors, such as novel 2-way peg mechanisms.
+of potentially controversial new behaviors like fully detailed introspection,
+which includes the ability to inspect parent transactions and novel 2-way peg
+mechanisms. ([CAT-tricks-I] [CAT-tricks-II] by Andrew Poelstra)
 
 Alternatively `OP_RETURN` could be used to ensure the availability of the state
 recovery data, as `OP_CHECKTEMPLATEVERIFY` naturally commits to all outputs.
@@ -172,6 +183,7 @@ various reasons, either for expanding the scope or for unnecessary complexity:
 * OP_CHECKTEMPLATEVERIFY committing to the taproot annex in tapscript
 * OP_CHECKSIGFROMSTACK on n elements as message
 * OP_VECTORCOMMIT: generalized form for n > 2 elements
+* ReKey: key delegation and multiple use of OP_CHECKSIGFROMSTACK
 
 ### Cost comparison of LN-Symmetry constructions
 
@@ -191,16 +203,16 @@ same size for both Force Close and Contest in LN-Symmetry, ForceC: total cost of
 Merkle trees can be used to prove computation where the root of the tree
 represents the *function* and the leaves represent the *inputs* and *output*.
 There are practical limits to the entropy space for the *inputs* as they need
-to be iterated over and hashed into a merkle root.
+to be iterated over and hashed into a Merkle root.
 
-MAST trees can currently cover 128 bits of entropy space, which is well over
-the practical limits to iterate over and merklize. Therefore, we assume this
+Taproot MAST trees can currently cover 128 bits of entropy space, which is over
+the practical limits to iterate over and merklize. Therefore, we conclude this
 capability does not materially extend what computations are possible to prove
 in bitcoin script. While `OP_PAIRCOMMIT` is not limited to a height of 128,
 that should not be practically feasible to utilize.
 
 There is a way to reduce the size of the witness for proving computation,
-by eliminating the merkle path inclusion proofs, using `OP_CHECKSIGFROMSTACK`
+by eliminating the Merkle path inclusion proofs, using `OP_CHECKSIGFROMSTACK`
 together with `OP_PAIRCOMMIT`. This method involves deleted key assumptions,
 most likely using MPC to create an enormous amount of signatures for the stack
 elements representing the *inputs* and the *output* of the *function*.
@@ -236,6 +248,8 @@ This document is licensed under the 3-clause BSD license.
 
 [lnhance]: https://github.com/lnhance/bitcoin
 [eltoo]: https://github.com/instagibbs/bolts/blob/eltoo_draft/XX-eltoo-transactions.md
+[CAT-tricks-I]: https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298
+[CAT-tricks-II]: https://medium.com/blockstream/cat-and-schnorr-tricks-ii-2f6ede3d7bb5
 
 [//]: # (BIPs referenced)
 [BIP-119]: https://github.com/bitcoin/bips/tree/master/bip-0119.mediawiki