# OP\_PAIRCOMMIT as a candidate for addition to LNhance **URL:** \ **Category:** Protocol Design\ **Created:** [October 25, 2024, 2:31pm UTC](https://delvingbitcoin.org/t/op-paircommit-as-a-candidate-for-addition-to-lnhance/1216 "2024-10-25T14:31:23Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![moonsettler](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/moonsettler/32/38_2.png) [@moonsettler](https://delvingbitcoin.org/u/moonsettler)\ **Post date:** [October 25, 2024, 2:31pm UTC](https://delvingbitcoin.org/t/op-paircommit-as-a-candidate-for-addition-to-lnhance/1216/1 "2024-10-25T14:31:23Z")
Hi All, Looking for some feedback on what I ended up with for PC. The idea is that the number of SHA256 iterations should be minimized in the most likely use case we can optimize for, which is LN-Symmetry. Since the Tag can be pre-computed as a mid-state it would only take 1 or 2 hash cycles in validation for the LN-Symmetry use case. In case of a 7 byte balance commitment + 32 byte CTV hash (no HTLCs in-flight), the total preimage size is 55 bytes. Which should make it fit into a single block with the SHA256 length commitment. In case there are 2x 32 byte CTV hash commitments, the first 64 byte block is comprised of those hashes, and the second block is the vectors’ size and total length commitment, which would be a largely 0 filled block with a very few bits set to 1. It’s a particular concern for LN-Symmetry with CTV that the concatenation of the two preimages allows for length redistribution attacks, because CTV is only defined for 32 byte templates and will act as NOP for different template sizes for upgradeability. The question is, is it a good idea to increase the number of bits expected to changed in the preimage in case of stack element resizing attacks? ```c++ const HashWriter HASHER_PAIRCOMMIT{TaggedHash("PairCommit")}; namespace { /* uint32_t hash function using primes 0x3B9ACA07 multiplier and 0x7FFFFFFF modulo * expected to change on average ~16 bits in output for a single bit change in input */ __inline uint32_t uint32_t_hash_x3B9ACA07(const uint32_t& i) { static const uint64_t p = 0x3B9ACA07; static const uint32_t m = 0x7FFFFFFF; return (p * i) % m; } } /* PairCommitHash preimage is expected to change over 32 bits on average in case of * length redistribution between the two input vectors */ uint256 PairCommitHash(const std::vector& x1, const std::vector& x2) { const uint32_t x1_size = x1.size(); const uint32_t x2_size = x2.size(); const uint32_t x1_sh = uint32_t_hash_x3B9ACA07(x1_size); const uint32_t x2_sh = uint32_t_hash_x3B9ACA07(x2_size); HashWriter ss{HASHER_PAIRCOMMIT}; ss << x1 << x2 << x1_size << x1_sh << x2_size << x2_sh; return ss.GetSHA256(); } ``` Link: [OP\_PAIRCOMMIT alternative with hash\_x3B9ACA07 by moonsettler · Pull Request #7 · lnhance/bitcoin · GitHub](https://github.com/lnhance/bitcoin/pull/7/files) ---
**Author:** ![moonsettler](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/moonsettler/32/38_2.png) [@moonsettler](https://delvingbitcoin.org/u/moonsettler)\ **Post date:** [October 25, 2024, 2:38pm UTC](https://delvingbitcoin.org/t/op-paircommit-as-a-candidate-for-addition-to-lnhance/1216/2 "2024-10-25T14:38:12Z")
From the prelimiary spec, where PC fits in LN-Symmetry: ### Vector Commitments `OP_PAIRCOMMIT` can be used to commit to a vector of stack elements in a way that is not vulnerable to various forms of witness malleability especially when used in conjunction with `OP_CHECKSIGFROMSTACK` and `OP_INTERNALKEY`, since SHA256 implicitly commits to size of the stack elements, making the script cleaner, and simpler. If `OP_CAT` was used naively, the contract could be easily broken since `OP_CHECKTEMPLATEVERIFY`is only defined for 32 byte parameters. ```plaintext # S = 500000000 # IK -> A+B | CTV PC IK CSFSV CLTV ``` before funding sign first state template: ```plaintext # state-n-hash { nLockTime(S+n), out(contract, amount(A)+amount(B)) } # settlement-n-hash { nSequence(2w), out(A, amount(A)), out(B, amount(B)) } # state-n-recovery-data { settlement-n-hash or state-n-balance } # contract for state n < m IF | CTV PC IK CSFSV CLTV ELSE CTV ENDIF ``` ---
**Author:** ![1440000bytes](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/1440000bytes/32/301_2.png) [@1440000bytes](https://delvingbitcoin.org/u/1440000bytes)\ **Post date:** [October 25, 2024, 5:57pm UTC](https://delvingbitcoin.org/t/op-paircommit-as-a-candidate-for-addition-to-lnhance/1216/3 "2024-10-25T17:57:14Z")
I am sorry but these new opcodes added to proposals will only delay or cancel them forever. I understand you like 2 things combined on the stack, OP\_CAT etc. but this brings a lot of complexity in something that needs to be kept simple. If we ever get OP\_CAT, maybe this could be possible with OP\_SHA256 and OP\_CAT at that moment. Its better if we get OP\_CTV activated first instead of trying to build the next Great Covenant Proposal. ---
**Author:** ![moonsettler](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/moonsettler/32/38_2.png) [@moonsettler](https://delvingbitcoin.org/u/moonsettler)\ **Post date:** [October 25, 2024, 7:06pm UTC](https://delvingbitcoin.org/t/op-paircommit-as-a-candidate-for-addition-to-lnhance/1216/4 "2024-10-25T19:06:11Z")
It would be possible with OP\_CAT to closely emulate OP\_PAIRCOMMIT, they are more complicated and or more expensive. We have redundancies in bitcoin script for much smaller optimizations. ```plaintext OP_SWAP OP_SIZE <0x00000001> OP_ADD OP_TOALTSTACK OP_SWAP OP_SIZE <0x00000001> OP_ADD OP_TOALTSTACK OP_CAT OP_FROMALTSTACK OP_CAT OP_FROMALTSTACK OP_CAT OP_HASH256 ``` or simply ```plaintext OP_HASH256 OP_SWAP OP_HASH256 OP_SWAP OP_HASH256 ``` ---
**Author:** ![moonsettler](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/moonsettler/32/38_2.png) [@moonsettler](https://delvingbitcoin.org/u/moonsettler)\ **Post date:** [October 25, 2024, 7:09pm UTC](https://delvingbitcoin.org/t/op-paircommit-as-a-candidate-for-addition-to-lnhance/1216/5 "2024-10-25T19:09:29Z")
But the question was really not about this, but rather if it makes any sense to do a mini-hashing of the sizes instead of static padding, for making the preimage more mutable when you redistribute bytes between the stack elements? The “original” variant: ```c++ const HashWriter HASHER_PAIRCOMMIT{TaggedHash("PairCommit")}; uint256 PairCommitHash(const std::vector& x1, const std::vector& x2) { // PAD is 0x00000001 in little endian serializaton const uint32_t PAD = 0x01000000; HashWriter ss{HASHER_PAIRCOMMIT}; ss << x1 << x2 << uint32_t(x1.size()) << PAD << uint32_t(x2.size()) << PAD; return ss.GetSHA256(); } ``` ---
**Author:** ![moonsettler](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/moonsettler/32/38_2.png) [@moonsettler](https://delvingbitcoin.org/u/moonsettler)\ **Post date:** [October 25, 2024, 9:50pm UTC](https://delvingbitcoin.org/t/op-paircommit-as-a-candidate-for-addition-to-lnhance/1216/7 "2024-10-25T21:50:45Z")
It’s okay, but I’m looking for opinions on the way these pieces are hashed, specifically from a security and efficiency pov. ---
**Author:** ![ajtowns](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/ajtowns/32/417_2.png) [@ajtowns](https://delvingbitcoin.org/u/ajtowns)\ **Post date:** [October 28, 2024, 11:16am UTC](https://delvingbitcoin.org/t/op-paircommit-as-a-candidate-for-addition-to-lnhance/1216/8 "2024-10-28T11:16:51Z")
> [@moonsettler](#): > > The idea is that the number of SHA256 iterations should be minimized in the most likely use case we can optimize for, which is LN-Symmetry. Not really seeing that as particularly important to minimise, personally; the difference between hashing 64 bytes and 256 bytes is pretty minor, compared to the checksig operation(s) you also have. I’d just write `[BAL] [CTVHASH] SHA256 SWAP SHA256 CAT SHA256`. > [@moonsettler](#): > > In case of a 7 byte balance commitment + 32 byte CTV hash (no HTLCs in-flight), the total preimage size is 55 bytes. Which should make it fit into a single block with the SHA256 length commitment. > [@moonsettler](#): > > It’s a particular concern for LN-Symmetry with CTV that the concatenation of the two preimages allows for length redistribution attacks, because CTV is only defined for 32 byte templates and will act as NOP for different template sizes for upgradeability. This seems as much an argument against doing upgradeability that way as anything else; but if you do want that, and want to minimise hashing as well for whatever reason, then writing `[BAL] [CTVHASH] SIZE 32 EQUALVERIFY CAT SHA256` seems like it would solve the problem. If you want to support CTV upgradeability prior to knowing what that upgradeability will do, you could do `[BAL] [CTVHASH] SIZE DUP VERIFY DUP 127 LESSTHANOREQUAL VERIFY SWAP CAT SWAP CAT SHA256` to construct `sha256(1B: ; 0B-127B: ; )`. (Having CTV error if the hash is 0 bytes would let you avoid the `DUP VERIFY` step and might be a reasonable update to the BIP) ---
**Author:** ![moonsettler](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/moonsettler/32/38_2.png) [@moonsettler](https://delvingbitcoin.org/u/moonsettler)\ **Post date:** [October 28, 2024, 11:58am UTC](https://delvingbitcoin.org/t/op-paircommit-as-a-candidate-for-addition-to-lnhance/1216/9 "2024-10-28T11:58:17Z")
> [@ajtowns](#): > > Having CTV error if the hash is 0 bytes would let you avoid the `DUP VERIFY` step and might be a reasonable update to the BIP Yes, don’t think there is a legitimate reason to have a 0 size argument for CTV. Thank you for the suggestion! Btw the PC code on that branch is broken, this is in good shape now: > > > \