BIP442: 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.

[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]

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

[moonsettler]

It looks like we gonna have to amend the PAIRCOMMIT BIP with some new use cases.
Turns out within certain practical limitations any computational function can be proven out in the form of a merkle tree.
The root hash of the merkle tree represents the function the leaves represent the inputs and output.
Any 32 bit arithmetic function can certainly be proven out with this method.
CAT itself with a limited set of inputs or limited input sizes can be proven out.
At this point it's an open question if this enables new behaviors not enabled by taproot MAST itself?

Special thanks to: @JeremyRubin @Ademan @bigspider

edit:
Alternatively could consider imposing specific script limits that make PAIRCOMMIT explicitly less capable than MAST itself.

[Ademan]

I think I've changed my mind a bit. We were talking about computing a merkle tree for f(u32,u32) as if it was trivial but after a quick experiment it seems like that would take hundreds of years to compute (am I being dumb here?) Instead, you can compute mul(u32,u32) -> u32 using 3 mul(u16,u16)s which is feasible to compute. The witness size is worse, ~32 * 32 * 3 = 3072 instead of 32 * 64 * 1 = 2048, but computing the tree for mul(u16,u16) is feasible using a naive algorithm on commodity hardware.

The implication of this is that where a function can be decomposed into operations on smaller inputs, PAIRCOMMIT is massively more feasible to use than encoding things into a tap tree.

[bigspider]

I think I've changed my mind a bit. We were talking about computing a merkle tree for f(u32,u32) as if it was trivial but after a quick experiment it seems like that would take hundreds of years to compute (am I being dumb here?) Instead, you can compute mul(u32,u32) -> u32 using 3 mul(u16,u16)s which is feasible to compute. The witness size is worse, ~32 * 32 * 3 = 3072 instead of 32 * 64 * 1 = 2048, but computing the tree for mul(u16,u16) is feasible using a naive algorithm on commodity hardware.

Arithmetic and bitwise operations where inputs & outputs are small enough, can already be done in Script in cheaper ways. Merkle trees as lookup tables are only interesting for functions that are either extremely complex, or where preimages/images are larger than what Script can work with.
Note that you can already do small indexed lookup tables more efficiently by just hard-coding them in Script (that is: push the table on the stack and use OP_PICK to read its entries), and these techniques are widely used (e.g. in BitVM).

The implication of this is that where a function can be decomposed into operations on smaller inputs, PAIRCOMMIT is massively more feasible to use than encoding things into a tap tree.

I think the only substantial difference is that in a Script where you need several lookups, you can do it with Merkle trees, while you can only do a single lookup with a precomputed taptree.

[moonsettler]

Proving general computation

Merkle trees can be used to prove out 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 it needs
to be iterated over and hashed up.

Currently MAST trees can cover 128 bits of entropy space, which is well over
the practical limits to iterate over and merklize. Therefore we assume this
capability does not materially extend what computations are possible to prove
out 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 out computation,
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.

Is this correct? Any suggestions? @Ademan @bigspider

[moonsettler]

The implication of this is that where a function can be decomposed into operations on smaller inputs, PAIRCOMMIT is massively more feasible to use than encoding things into a tap tree.

This is the main open question I believe. does it or does it not practically expand what we can already do?
For example using PC to emulate smolCAT and using traditional methods with lookup tables could make 32 bit or even 64 bit arithmetics more feasible?

edit:
Within the 32 bit realm we can already use OP_ADD, I see little practical diff between <0x1234> <0x5678> CAT and <0x12340000> <0x5678> ADD.
And it sounds like 64 bit smolCAT would be way too expensive to generate (and also to interact with trustlessly).

(actually the above examples are wrong, because internally bitcoin script uses little endian, but should convey the point)

[Ademan]

...

Arithmetic and bitwise operations where inputs & outputs are small enough, can already be done in Script in cheaper ways. Merkle trees as lookup tables are only interesting for functions that are either extremely complex, or where preimages/images are larger than what Script can work with. Note that you can already do small indexed lookup tables more efficiently by just hard-coding them in Script (that is: push the table on the stack and use OP_PICK to read its entries), and these techniques are widely used (e.g. in BitVM).

Even u16,u16 is quite a bit larger than I think is practical as a lookup table, but the efficiency for repeated operations is constant, obviously. The lookup table is less efficient for small numbers of operations (a u8,u8 table is 16k vs 1 u8,u8 proof is 0.4k) but the merkle tree loses quickly when those operations are repeated.

The implication of this is that where a function can be decomposed into operations on smaller inputs, PAIRCOMMIT is massively more feasible to use than encoding things into a tap tree.

I think the only substantial difference is that in a Script where you need several lookups, you can do it with Merkle trees, while you can only do a single lookup with a precomputed taptree.

Right, and the key point is these merkle trees and lookup tables rapidly become infeasible to compute as the input size grows, so multiple smaller lookups is significantly more useful.

EDIT: But your point is well taken that for smaller operations they can already be better accomplished by lookup tables.

[Ademan]

...
edit: Within the 32 bit realm we can already use OP_ADD, I see little practical diff between <0x1234> <0x5678> CAT and <0x12340000> <0x5678> ADD. And it sounds like 64 bit smolCAT would be way too expensive to generate (and also to interact with trustlessly).

(actually the above examples are wrong, because internally bitcoin script uses little endian, but should convey the point)

Yeah for arbitrary 8 byte strings smolCAT seems infeasible to compute the table or merkle tree for. After a bit of conversation on IRC it could probably be feasible for arbitrary f(b[4],b[4]) -> b[8] with a custom ASIC¹ or maybe a cluster of FPGAs in a span of ~a few years but that would not be very useful for the average person.

Bit shifts over 32 bit integers seems pretty feasible though, that's f(u32,u6)->u32 (maybe save some space by special casing shift = 0). it seems like my incredibly naive, unoptimized, single-core experiment could calculate that merkle tree in ~96 hours. Of course the proof is ~1.2k and users would likely need multiple, but the lookup table for that wouldn't fit in a block anyway so maybe something new is possible?

You can also separate positive and negative shifts, and maybe break it down into multiple rounds of shifts 1-3 or something (or 1k for a proof for a constant shift)

[1]: afaik existing ASICs operate on block headers so couldn't help

[murchandamus]

Looking for feedback, is this a better direction to continue with? https://github.com/lnhance/bips/blob/paircommit-rework/bip-0442.md

What you link to here reads very well. Skimming the current content of this PR, I would say the linked rework is more promising.

[moonsettler]

This is more my words and my thought process, would it be okay to reference it as previous iteration or something?
https://gist.github.com/moonsettler/d7f1fb88e3e54ee7ecb6d69ff126433b

[murchandamus]

I’m happy to review again whatever is submitted here, but I don’t have the bandwidth to involve myself in the writing of the proposal. Please let me know when you have picked the version you want to submit.

[murchandamus]

I saw that you set this pull request to “ready for review”, but then pushed more changes. Do I take it right that you are ready for editor review, @moonsettler?

[moonsettler]

Sorry I found some errors after. But yes, it is ready for review now.

[moonsettler]

Small fix to the LN-Symmetry script example and rebased to latest.

[moonsettler]

Should add TEMPLATEHASH+IKEY+CSFS comparisions?

Suggested change

	| Method | ChannelSc | UpdateSc | UpdateW | ForceC | Contest | Settle |
	| :--------------- | --------: | -------: | ------: | ------: | ------: | :----: |
	| APO-Annex | 8 WU | 113 WU | 100 WU | 1221 WU | 627 WU | SigOp |
	| APO-Return | 8 WU | 113 WU | 66 WU | 1359 WU | 765 WU | SigOp |
	| CTV+CSFS | 43 WU | 81 WU | 98 WU | 1394 WU | 765 WU | CTV |
	| CTV+CSFS+IKEY | 10 WU | 48 WU | 98 WU | 1328 WU | 732 WU | CTV |
	| CTV+CSFS+IKEY+PC | 11 WU | 49 WU | 131 WU | 1191 WU | 594 WU | CTV |
	*ChannelSc: channel script, UpdateSc: update script, UpdateW: witness size for Force Close and Contest, ForceC: cost of unilateral close, Contest: additional cost to contest, Settle: signature or CTV required for settlement.*
	| Method | ChannelSc | UpdateSc | UpdateW | ForceC | Contest | Settle |
	| :--------------- | --------: | -------: | ------: | ------: | ------: | :----: |
	| APO-Annex | 8 WU | 113 WU | 100 WU | 1221 WU | 627 WU | SigOp |
	| APO-Return | 8 WU | 113 WU | 66 WU | 1359 WU | 765 WU | SigOp |
	| CTV+CSFS | 43 WU | 81 WU | 98 WU | 1394 WU | 765 WU | HashEq |
	| CTV+CSFS+IKEY | 10 WU | 48 WU | 98 WU | 1328 WU | 732 WU | HashEq |
	| CTV+CSFS+IKEY+PC | 11 WU | 49 WU | 131 WU | 1191 WU | 594 WU | HashEq |
	| THIKCS-Annex | 10 WU | 49 WU | 100 WU | 1160 WU | 563 WU | HashEq |
	| THIKCS-Return | 10 WU | 49 WU | 66 WU | 1295 WU | 699 WU | HashEq |
	*ChannelSc: channel script, UpdateSc: update script, UpdateW: witness size for Force Close and Contest, ForceC: cost of unilateral close, Contest: additional cost to contest, Settle: signature or hash equality check required for settlement, THIKCS: TEMPLATEHASH+IKEY+CSFS.*