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.

[murchandamus]

I would like to see this proposal to get more review from other covenant researchers before it moves forward.

[murchandamus]

This paragraph seems to indicate that the OP_PAIRCOMMIT proposal would be especially useful in combination with these other opcodes. Could you perhaps clarify whether and how OP_PAIRCOMMIT is useful by itself in absence of the other three opcodes you mention here?

[moonsettler]

LNhance at it's core is CTV + CSFS. They together provide the core utility. IKEY is an optimization for not having to pay for the pubkey twice when the internal key can be used. PC is an optimization when CSFS has to commit to additional data required to recreate a spend script from an intermediate state, because OP_RETURN (to which CTV naturally commits to) is 4x more expensive in weight units for data availability.

PC could also be used by CHECKCONTRACTVERIFY to carry a complex state in the absence of CAT.

I don't think anyone would find PC useful enough to activate in isolation without the aforementioned other opcodes.
It can do general merkle tree style commitments that are not compatible with other merkle tree structures in bitcoin.

We probably will make a new BIP for LNhance that has these other BIPs as "Relies on".

[rot13maxi]

consider linking to the section in bip340 about tagged hashes

[moonsettler]

It is linked from Specification (line 53), not sure I would want to link from here.

[rot13maxi]

what data needs to be available? how does PC solve that problem (does it stick the data in the witness and put a commitment somewhere covered by a signature? something else?)? Is this mechanism useful for things outside of LN-Symmetry?

[moonsettler]

The data that needs to be available for state n is:

state-n-recovery-data { settlement-n-hash or state-n-balance }

This is needed to reconstruct the whole script for the nth state address that the funds move to by the channel peer that only holds the latest state, so he can spend to the latest state.

edit:
Instead of an IF statement we could use different tap leaves (less optimal actually) and then merkle inclusion proof with sibling hashes would have to be known.

[moonsettler]

Is this mechanism useful for things outside of LN-Symmetry?

It was obviously our primary motivation, but I would not be surprised if other applications that use CSFS find a similar use for it.

[moonsettler]

One way to think about the 3 opcodes (CSFS, IKEY, PC) is we decompose a CSFS variant that can use 1 byte pubkey (internal key) and can commit to a vector of stack elements as message. They thus become more generally useful, but to a limited degree without additional opcodes.

Detailed introspection opcodes would also need vector commitments with CSFS, and as mentioned it would also be useful for CCV.