OP_PAIRCOMMIT

[moonsettler]

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:

• 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.

Discussion: https://delvingbitcoin.org/t/op-paircommit-as-a-candidate-for-addition-to-lnhance/1216/12

[murchandamus]

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.

[moonsettler]

Switched back to markdown. Header now in BIP-2 format.

[moonsettler]

The original create date of OP_PAIRCOMMIT is 2024-03-15 this is the latest revision based on feedback from Anthony Towns.
https://gist.github.com/moonsettler/d7f1fb88e3e54ee7ecb6d69ff126433b/revisions
What date should go to the header?

[jonatack]

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.

[murchandamus]

According to BIP 2:

The Created header records the date that the BIP was assigned a number, […]

[murchandamus]

Has this proposal been sent to the mailing list?

[moonsettler]

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.

[murchandamus]

It sounds like OP_PAIRCOMMIT is closely related to CAT and CSFS. Could you perhaps expand on the related work and design decisions in a Rationale section?

[moonsettler]

Alternatives we discussed:

• OP_CAT
• Merkle operation opcodes
• SHA256 streaming opcodes
• 'Kitty' CAT (result or inputs limited in size to try disable introspection and arithmetic extension uses)
• OP_CTV also commiting to the taproot annex in tapscript
• OP_CHECKSIGFROMSTACK variant on n elements as message instead of 1
• OP_VECTORCOMMIT (decoupling above behavior)

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.

[murchandamus]

That’s why I am suggesting that this proposal should collect some of that information.

[moonsettler]

I would prefer to keep it simple and to the point. Added a more brief rationale section. Could do a more in depth recollection on what we learned and why certain alternatives fell out of favor on a delving thread we link from here, if people are actually curious.

[moonsettler]

Expanded on the rationale behind OP_PAIRCOMMIT on delvingbitcoin.