OP_PAIRCOMMIT is the newest member of the LNhance family of opcodes. It provides limited vector commitment functionality in tapscript.
When evaluated, the OP_PAIRCOMMIT instruction:
Discussion: https://delvingbitcoin.org/t/op-paircommit-as-a-candidate-for-addition-to-lnhance/1216/12
This document has a few formatting issues, please make sure that the preamble matches the BIP 2 requirements and take a look at the rich diff to see whether it looks the way you intend.
Please note that the BIPs repository also accepts markdown files.
Added a discussion link to the PR description.
The original create date of OP_PAIRCOMMIT is 2024-03-15 this is the latest revision based on feedback from Anthony Towns. gist.github.com/moonsettler/d7f1fb88e3e54ee7ecb6d69ff126433b/revisions What date should go to the header?
Perhaps add a changelog with the revision based on Anthony Towns’ feedback followed by the initial version. Or use the date of the current draft revision as your starting point.
According to BIP 2:
The Created header records the date that the BIP was assigned a number, […]
Has this proposal been sent to the mailing list?
Not yet. Wanted to get it into an acceptable shape before I post it there.
Proposed to the mailing list, waiting for feedback.
1266@@ -1267,6 +1267,13 @@ Those proposing changes should consider that ultimately consent may rest with th
1267 | Gloria Zhao
1268 | Informational
1269 | Draft
1270+|- style="background-color: #cfffcf"
For Draft status PRs the background color is not specified
0|-
1266@@ -1267,6 +1267,13 @@ Those proposing changes should consider that ultimately consent may rest with th
1267 | Gloria Zhao
1268 | Informational
1269 | Draft
1270+|- style="background-color: #cfffcf"
1271+| [[bip-PC.md|PC]]
1272+| Consensus (soft fork)
1273+| PAIRCOMMIT
This has to match the title header in the preamble:
0| OP_PAIRCOMMIT
34+
35+If `OP_CAT` was available, it could be used to combine multiple stack elements,
36+that get verified with `OP_CHECKSIGFROMSTACK` as a valid state update.
37+
38+`OP_PAIRCOMMIT` solves this specific problem without introducing a wide range
39+of potentially controversial new behaviors, such as novel 2-way peg mechanisms.
Alternatives we discussed:
Finally after weighing everything OP_PAIRCOMMIT was the simplest addition that got what we needed exactly in the most efficient way. It’s a minimal code change, very easy to reason about. Therefore we expect it to be the least controversial option.
Sadly a lot of the discussion is all over the place and on unsearchable mediums.
Remove style, Correct title
129+## Reference Implementation
130+
131+A reference implementation is provided here:
132+
133+https://github.com/lnhance/bitcoin/pull/6/files
134+
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.
OP_PAIRCOMMIT solves this specific problem without introducing a wide range
of potentially controversial new behaviors, such as novel 2-way peg mechanisms.
OP_CAT allows for fine grained introspection possibly bigint operations and
extending the arithmetic capabilities of bitcoin script using lookup tables.
These would predictably allow for the same functionality as OP_CAT for
introspection purposes, since verification of a computation is largely
equivalent with carrying it out. Bigint and new arithmetic operations would
be hard or even impossible.
These would be of very limited general use and hard to rationalize without OP_CAT. Their complexity and resource cost is hard to justified for vector commitments only. Compatibility considerations with taproot MAST were also hard to resolve without knowing what other opcodes may be activated in the future.
The original idea would have limited the maximum size of OP_CAT output to a
size that is smaller than the smallest sighash preimage, thus disabling the
introspection capabilities and trivial ways to extend the arithmetic repertoir
of bitcoin script. This turned out to be an awkward, arbitrary and offering
weak .
A CTV template can be considered a sighash, however relaxing the relay policy to take advantage of this change would make various endogenous asset protocols more efficient, and therefore be controversial. There is also no consensus on how to use or how to structure the annex.
This was previosuly discussed and also implemented, it complicates the code and is a pretty arbitrary coupling of behaviors.
The obvious generalized solution for committing to n stack elements, however it involves looping and hard to argue about setting the proper limits to it.
Labels
New BIP