BIP442: OP_PAIRCOMMIT #1699

moonsettler · 2024-11-11T23:07:43Z

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 · 2024-11-13T20:16:18Z

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

moonsettler · 2024-11-13T21:49:30Z

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 · 2024-11-14T02:39:23Z

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 · 2024-11-14T15:51:53Z

According to BIP 2:

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

murchandamus · 2024-11-14T22:10:02Z

Has this proposal been sent to the mailing list?

moonsettler · 2024-11-14T22:16:33Z

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.

README.mediawiki

bip-PC.md

murchandamus

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

bip-PC.md

moonsettler · 2024-11-26T20:09:19Z

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 · 2024-11-27T05:40:45Z

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 · 2024-11-27T09:39:06Z

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 · 2024-11-27T14:32:54Z

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 · 2024-11-27T14:37:53Z

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 · 2024-11-27T15:07:42Z

...

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 · 2024-11-27T17:20:40Z

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

Let’s call this BIP 442.

bip-PC.md

README.mediawiki

reardencode

PAIRCOMMIT continues to grow on me.

Getting the primary benefits of OP_CAT without introducing ugly introspection seems like a clear win for bitcoin.

Better introspection should also be added in follow-up forks. Thanks for your work on this!

bip-0442.md

reardencode · 2024-12-24T16:51:52Z

bip-0442.md

+a 1-byte `OP_TRUE` public key (substituting for the *taproot internal key*) and
+can commit to a number of stack elements as a message.
+
+### Behaviors LNhance tries to avoid introducing


Does this section belong in the PC BIP?

Maybe we should have an LNhance BIP that depends on the others and move some stuff over?

I think it may be fine here if this section is moved up next to the Motivation section and the term LNHANCE is introduced clearly, ideally with a link to lnhance.org if that url is viable long-term.

bip-0442.md

JeremyRubin · 2024-12-24T17:37:44Z

I get that there is a goal here to avoid introspection...

but it seems that it'd be more generically useful if the function were e.g., a TapBranch function, so then it could be used in the future with some other taproot editing opcodes.

e.g., if OP_TAPBRANCHCOMMIT were to lexicographic sort, then cat, then commit, you could do paircommit like functionality by doing:

<a> TUCK OP_TAPBRANCHCOMMIT OP_TAPBRANCHCOMMIT

this works because while the first commit commits to either a||b or b||a, and also has sliceable errors (e.g., (a||b)[:i] and (a||b)[i:]), the second commit re-commits to  and it's length which uniquely determines order and prevents sliceable errors.

One concern: OP_TAPBRANCHCOMMIT is witness "malleable", in that items could show up in the witness stack in either order and get the same result. It'd still be possible to make non-malleable witnesses by requiring the stack elements to be in order with a OP_LEXSORT or equivalent functionality.

moonsettler · 2024-12-24T20:13:10Z

If we did OP_TAPBRANCHCOMMIT then with OP_CHECKCONTRACTVERIFY I believe you get TLUV behavior?
You can verify a tapleaf on the input and can also replace it with an other on the output?

To be honest the OP_PAIRCOMMIT domain separation was aimed to prevent the possibility of such uses as potentially being more controversial.

JeremyRubin · 2024-12-25T00:59:18Z

I think it's actually less controversial, because if you do OP_TAPBRANCHCOMMIT you're doing something that even once you have OP_CAT, is really handy to have (because sorting two strings is actually still pretty hard with CAT).

Whereas now you're getting a lot of people thinking that paircommit is not so useful if CAT gets in eventually.

moonsettler · 2024-12-25T01:13:58Z

Right. I did consider something like a sorting merkle operator for lamport stuff for example, however when you need order dependent commitments (which is pretty much everything we are doing with it rn) then you would have to use a dummy value like:
<a> <1> OP_TAPBRANCHCOMMIT OP_TAPBRANCHCOMMIT
or maybe:
<a> OP_SHA256 OP_TAPBRANCHCOMMIT
instead of:
<a> OP_PAIRCOMMIT
So if I wanted to support both of these functionalities I would probably end up with 2 separate opcodes for them.

moonsettler · 2024-12-28T17:52:26Z

I think this is ready for a merge from my point of view.
Rebased to latest master and squashed all the changes to 1 commit.

Ademan · 2024-12-28T18:44:26Z

Maybe this is obvious to everyone else and I'm a slowpoke here, but PC+CSFS+CTV enables a kind of "multi-transaction-signature". You sign a merkle root that commits to a bunch of CTV transaction templates, and you can provide an inclusion proof with PC with the signature.

I've been spitballing with someone about a multiparty eltoo scheme and came up with a way to bound the state resolution but without state carrying covenants it requires a possible field of ~2^N transactions (of which, at most N will end up on-chain), and every party shares N*(N+1)/2 signatures.

With PC+CSFS+CTV it still requires ~2^N transactions, but each party only needs to share their 1 signature over the merkle root.

EDIT: Not 100% sure it works for my mutliparty eltoo scheme just yet, but I'm still >50% confident it does...
EDIT EDIT: More confident it works, but it looks like the number of transactions is exponential rather than polynomial... and so my estimate for how many signatures would need to be shared without the "multi-transaction-signature" commitment is probably way low.
EDIT EDIT EDIT: I genuinely have no idea how I decided "multi-signature" was an acceptable term considering it already has a different meaning in Bitcoin... s/"multi-signature"/"multi-transaction-signature"/g

murchandamus

I find this BIP still somewhat hard to read. Many sections seem to expect a lot of prior knowledge from the reader. Overall, it seems to me that several sections could do with a bit more context. Maybe I’m not in the target audience for the BIP, but I would suggest that people who are more invested in this topic proofread this BIP and provide feedback with approachability in mind.

murchandamus · 2024-12-30T18:08:12Z

bip-0442.md

+<a> <b> <c> | PC PC <pc-hash> OP_EQUALVERIFY
+```
+
+### Use in LN-Symmetry


This is a subsection of the Specification section, but does "Use in LN-Symmetry" actually belong to the Specification? Wouldn’t it make more sense for it to be in the Rationale or a section with example uses?

murchandamus · 2024-12-30T18:08:38Z

bip-0442.md

+ENDIF
+```
+
+### Use with future updates


Same as above, "Use with future updates" doesn’t seem to belong to the Specification.

Using ## instead of ### for this section and for "Use in LN-Symmetry" might suffice (e.g. moving them out of the Specification section).

murchandamus · 2024-12-30T18:14:24Z

bip-0442.md

+| 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+IKEY |     10 WU |    48 WU |   98 WU | 1328 WU |  732 WU |  CTV   |
+| CTV+CSFS      |     43 WU |    81 WU |   98 WU | 1394 WU |  765 WU |  CTV   |
+| LNhance       |     11 WU |    49 WU |  131 WU | 1191 WU |  594 WU |  CTV   |
+
+*ChannelSc: channel script, UpdateSc: update script, UpdateW: witness is the
+same size for both Force Close and Contest in LN-Symmetry, ForceC: total cost of unilateral close transactions*


Some of these abbreviations are just a few characters shorter than the actual term. How about something along the lines of:

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+IKEY | 10 WU | 48 WU | 98 WU | 1328 WU | 732 WU | CTV |

| CTV+CSFS | 43 WU | 81 WU | 98 WU | 1394 WU | 765 WU | CTV |

| LNhance | 11 WU | 49 WU | 131 WU | 1191 WU | 594 WU | CTV |

*ChannelSc: channel script, UpdateSc: update script, UpdateW: witness is the

same size for both Force Close and Contest in LN-Symmetry, ForceC: total cost of unilateral close transactions*

| Method | Channel Script | Update Script | Update Witness¹ | Force Close² | Contest | Settlement Mechanism |

| :------------ | --------: | -------: | ------: | ------: | ------: | :----: |

| 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+IKEY | 10 WU | 48 WU | 98 WU | 1328 WU | 732 WU | CTV |

| CTV+CSFS | 43 WU | 81 WU | 98 WU | 1394 WU | 765 WU | CTV |

| LNhance | 11 WU | 49 WU | 131 WU | 1191 WU | 594 WU | CTV |

¹ *witness is the same weight for both Force Close and Contest in LN-Symmetry*

² *total cost of unilateral close transactions*

This table is also provided barren of context. It would probably be useful to link to the compared schemas, or to the source of the table, and to add a couple sentence as to what we are looking at in the first place.

murchandamus · 2024-12-30T18:14:31Z

bip-0442.md

+* OP_VECTORCOMMIT: generalized form for n > 2 elements
+* ReKey: key delegation and multiple use of OP_CHECKSIGFROMSTACK
+
+### Cost comparison of LN-Symmetry constructions


Suggested change

### Cost comparison of LN-Symmetry constructions

### Weight comparison of LN-Symmetry constructions

This comment was not addressed in the recent update.

murchandamus · 2024-12-30T18:22:42Z

bip-0442.md

+### Behaviors LNhance tries to avoid introducing
+
+The following behaviors are out of scope for LNhance and should not be enabled


This is the first mention of LNHANCE in this BIP, but is not further explained. LNHANCE is not introduced in this repository (except for a cursory mention in BIP 348 OP_CHECKSIGFROMSTACK). It would probably make sense to introduce the term, if this section is retained.

murchandamus · 2024-12-30T18:30:27Z

bip-0442.md

+There are practical limits to the entropy space for the *inputs* as they need
+to be iterated over and hashed into a Merkle root.
+
+Taproot MAST trees can currently cover 128 bits of entropy space, which is over


What are "Taproot MAST trees"? The taproot BIPs speaks of "Script Trees" and MAST would be understood as "Merklized Alternative Script Trees" in the context of Taproot. On the other hand, MAST as described in BIP 114 and BIP 117 speaks of Merklized Abstract Syntax Trees where multiple leaves are used in combination.

You mention MAST here in the context taproot, where only a single leaf is ever used at once, but it seems to me that you might be thinking of Abstract Syntax Trees. Either way, it is not clear to me what you are referring to here, when you speak of the "entropy space covered by Taproot MAST trees" while treating leaves as "inputs and outputs".

This section is jumping right in the middle of something. I’m not sure that the scenario is described sufficiently to understand what the supposed concern is, let alone why the supposed concern is not a concern. If this section is relevant to this BIP, I reckon that more context is necessary for the reader to understand why and how, e.g., add aa link to a description of this scheme, or provide a bit more explanation what this section is talking about.

IMO this is a problem in the taproot BIP series, where various individuals decided it pertinent to change a well understood acronym (MAST) to suit taproot, rather than resepcting an existing body of literature including other BIPs.

I'd rather the taproot BIPs get updated to reflect the terminology Merklized Abstract Syntax Trees (or Tap Script Merkle Commitments, TSMC, if we're fond of confusing backronyming but should be less ambiguous in context) rather than Merklized Alternative Script Trees, which was a backronym.

correction: it seems there is no mention of alt script tree in the bips repos, just abstract syntax tree, including in the BIPs for Taproot itself. It's just a confusing rename people have made outside of this repo.

So should it be "Taptrees" instead of "Taproot MAST trees"? Or "Tapscript trees"?

I think "Taproot script tree" or "Taproot Merkle tree" would both be clear, I prefer the former.

reardencode

I'm gonna spend some time with this BIP today and will either make comments or offer a revision to put the sections of this into a more cohesive sequence.

reardencode · 2024-12-31T00:30:03Z

bip-0442.md

+Currently, bitcoin lacks a way to hash multiple stack elements together. Which
+means building Merkle trees or verifying inclusion in a tree is not supported.


Suggested change

Currently, bitcoin lacks a way to hash multiple stack elements together. Which

means building Merkle trees or verifying inclusion in a tree is not supported.

Currently, bitcoin lacks a way to commit to multiple stack elements together. It is common practice to hash a single item as part of a bitcoin script, either in hash/time locked contracts, or in pay-to-pubkey-hash (P2PKH) scripts, but there is no way to commit to multiple items with a single hash.

In a contrived but demonstrative example, if PAIRCOMMIT existed in legacy script, P2PKH could be extended to pay-to-pubkey-time-hash with scriptPubKey `2DUP PAIRCOMMIT RIPEMD160 <hash> EQUALVERIFY CHECKLOCKTIMEVERIFY DROP CHECKSIG`. This script format for single signature, time-locked bitcoin could be transformed into an address format.

With the ability to commit to pairs of elements, PAIRCOMMIT can be generalized Merklized commitments to a tree of elements with a single hash. On its own, this could enable a hash lock contract where the holder of any pre-image in a Merkle tree can unlock the spend, for example.

If `OP_CHECKSIGFROMSTACK` is combined with PAIRCOMMIT, the ability to sign commitments to multiple items enables both of the above but as a form of delegation. In cases where any single item can be used to unlock an output, additional off chain signatures be simply can be used as an alternative to PAIRCOMMIT. However in cases where multiple items must be used for spending together, PAIRCOMMIT removes the need for complex laddering schemes to ensure that all items were authorized together.

reardencode · 2024-12-31T00:30:22Z

bip-0442.md

+The number of SHA256 iterations is minimized in the typical use cases we can
+optimize for. Since the Tag can be pre-computed as mid-state, it would only
+take 1 or 2 hash cycles in validation for the unilateral close scenario.


This seems like something that belongs in a footnote not in the main text.

reardencode · 2024-12-31T15:58:37Z

bip-0442.md

+There are practical limits to the entropy space for the *inputs* as they need
+to be iterated over and hashed into a Merkle root.
+
+Taproot MAST trees can currently cover 128 bits of entropy space, which is over


I think "Taproot script tree" or "Taproot Merkle tree" would both be clear, I prefer the former.

jonatack

WIP review.

jonatack · 2025-01-04T02:34:33Z

bip-0442.md

+in a way that makes length redistribution attacks infeasible.
+
+The number of SHA256 iterations is minimized in the typical use cases we can
+optimize for. Since the Tag can be pre-computed as mid-state, it would only


Does "Tag" here refer to this, as you are writing elsewhere in this draft?

Suggested change

optimize for. Since the Tag can be pre-computed as mid-state, it would only

optimize for. Since the tagged SHA256 hash can be pre-computed mid-state, it would only

drop "as"?

s/in validation/to validate/ (line 34)?

jonatack · 2025-01-04T03:00:59Z

bip-0442.md

+ENDIF
+```
+
+### Use with future updates


Using ## instead of ### for this section and for "Use in LN-Symmetry" might suffice (e.g. moving them out of the Specification section).

jonatack · 2025-01-04T03:02:37Z

bip-0442.md

+### Use with future updates
+
+Detailed introspection opcodes would also need vector commitments when used
+with `OP_CHECKSIGFROMSTACK`.


nit, could link to or mention BIP348 with CHECKSIGFROMSTACK here.

jonatack · 2025-01-04T03:05:33Z

bip-0442.md

+Detailed introspection opcodes would also need vector commitments when used
+with `OP_CHECKSIGFROMSTACK`.
+
+`OP_CHECKCONTRACTVERIFY` would also need a way to carry complex data.


This isn't part of any BIP (number) yet, maybe add it later if that changes.

jonatack · 2025-01-04T03:10:31Z

bip-0442.md

+
+https://github.com/lnhance/bitcoin/pull/6/files
+
+## Rationale


Suggest moving this Rationale section up to just after Motivation, before Specification.

jonatack · 2025-01-04T03:13:25Z

bip-0442.md

+
+## Rationale
+
+If `OP_CAT` was available, it could be used to combine multiple stack elements


Could link to or mention BIP347 with OP_CAT here.

jonatack · 2025-01-04T03:14:16Z

bip-0442.md

+* Merkle operation opcodes
+* 'Kitty' CAT: result or inputs arbitrarily limited in size
+* OP_CHECKTEMPLATEVERIFY committing to the taproot annex in tapscript
+* OP_CHECKSIGFROMSTACK on n elements as message


could link to or mention BIP348

jonatack · 2025-01-04T03:15:01Z

bip-0442.md

+* SHA256 streaming opcodes
+* Merkle operation opcodes
+* 'Kitty' CAT: result or inputs arbitrarily limited in size
+* OP_CHECKTEMPLATEVERIFY committing to the taproot annex in tapscript


Could link to or mention BIP119

jonatack · 2025-01-04T03:16:27Z

bip-0442.md

+* OP_VECTORCOMMIT: generalized form for n > 2 elements
+* ReKey: key delegation and multiple use of OP_CHECKSIGFROMSTACK
+
+### Cost comparison of LN-Symmetry constructions


It may make sense to put this section next to (or in) the "Use in LN-Symmetry" section.

jonatack · 2025-01-04T03:23:46Z

bip-0442.md

+a 1-byte `OP_TRUE` public key (substituting for the *taproot internal key*) and
+can commit to a number of stack elements as a message.
+
+### Behaviors LNhance tries to avoid introducing


I think it may be fine here if this section is moved up next to the Motivation section and the term LNHANCE is introduced clearly, ideally with a link to lnhance.org if that url is viable long-term.

jonatack · 2025-01-04T03:47:36Z

bip-0442.md

+Channel peers must be able to reconstruct the script that spends an
+intermediate state.
+
+Using in sequence `OP_CHECKTEMPLATEVERIFY`, `OP_PAIRCOMMIT`, `OP_INTERNALKEY`


The pseudocode below might be clearer if the acronyms are defined beforehand

Suggested change

Using in sequence `OP_CHECKTEMPLATEVERIFY`, `OP_PAIRCOMMIT`, `OP_INTERNALKEY`

Using in sequence `OP_CHECKTEMPLATEVERIFY` (`CTV`), `OP_PAIRCOMMIT` (`PC`), `OP_INTERNALKEY` (`IK`)

(idem for CSFS on the next line)

reardencode · 2025-01-04T04:15:47Z

Thanks so much Jon. we have a significant revision coming that does include defining abbreviations. @moonsettler should we move this to draft until we finish workshopping the revisions we're working on?

moonsettler · 2025-02-08T18:39:24Z

We have a rework of the BIP, the original can be viewed here

Please provide feedback on which approach you think is better! @murchandamus @jonatack

murchandamus

Thanks, I found the new version easier to follow.

murchandamus · 2025-02-10T18:02:59Z

bip-0442.md

+is common practice to hash a single item as part of a bitcoin script. Either
+in hash/time locked contracts, or in pay-to-pubkey-hash (P2PKH) scripts, but
+there is no way to commit to multiple items with a single hash. 


The sentence starting with "Either" seems to be missing one or more words.

murchandamus · 2025-02-10T18:08:44Z

bip-0442.md

-construction that provides data availability to spend to the latest state from
-an earlier state pushed on-chain with a forced close by channel partner.
-
+### Use in Lightning Symmetry


I think "LN-Symmetry" is more commonly used to refer to the concept than "Lightning Symmetry". Is there a specific reason why you prefer the latter?

murchandamus · 2025-02-10T18:21:58Z

bip-0442.md

+by contested closes. Specifically, the second to act channel partner must be
+able to reconstruct the script that spends the first update transaction
+published. This script includes the hash of the corresponding settlement


Maybe this is easier to parse:

Suggested change

by contested closes. Specifically, the second to act channel partner must be

able to reconstruct the script that spends the first update transaction

published. This script includes the hash of the corresponding settlement

by contested closes. Specifically, either channel partner must be

able to spend the output of any prior update transaction.

Those input scripts include the hash of the corresponding settlement

murchandamus · 2025-02-10T18:23:17Z

bip-0442.md

+transaction which we do not wish to store for all prior states. By having the
+channel and update state scripts force the parties to include the settlement
+transaction's hash in the witness to in order to publish the corresponding
+update transaction, then a later update can use the settlement hash from the


I’m stumbling over this "in the witness to in order". Could you please revisit this sentence?

murchandamus · 2025-02-10T18:35:43Z

bip-0442.md

-most likely using MPC to create an enormous amount of signatures for the stack
-elements representing the *inputs* and the *output* of the *function*.
+Taproot trees can be 128 levels deep, therefore including up to 2^128 possible
+output values. This is over the practical limits to enumerate and merkelize.


Consistency nit:

Suggested change

output values. This is over the practical limits to enumerate and merkelize.

output values. This is over the practical limits to enumerate and Merklize.

murchandamus · 2025-02-10T18:43:38Z

bip-0442.md

+same size for both Force Close and Contest in Lightning Symmetry, ForceC: total
+cost of unilateral close transactions, Contest: The additional cost to contest
+a force closure, Settle: Whether a signature operation or CTV operation is
+required to validate the settlement transaction*


Thanks for expanding on the column titles. As I wrote above, it would be good to provide more context for this table. It would especially help if the compared schemata were at least briefly described and/or sources for details were provided.

murchandamus · 2025-02-10T18:43:53Z

bip-0442.md

+* OP_VECTORCOMMIT: generalized form for n > 2 elements
+* ReKey: key delegation and multiple use of OP_CHECKSIGFROMSTACK
+
+### Cost comparison of LN-Symmetry constructions


This comment was not addressed in the recent update.

murchandamus · 2025-02-10T18:46:49Z

bip-0442.md

-most likely using MPC to create an enormous amount of signatures for the stack
-elements representing the *inputs* and the *output* of the *function*.
+Taproot trees can be 128 levels deep, therefore including up to 2^128 possible
+output values. This is over the practical limits to enumerate and merkelize.


The first time I read this paragraph, I was confused and didn’t realize that you were comparing the expressional power of OP_PAIRCOMMIT and P2TR.
Perhaps it would help if you write "leaf scripts" instead of "output values" here:

Suggested change

output values. This is over the practical limits to enumerate and merkelize.

leaf scripts. This is over the practical limits to enumerate and merkelize.

bip-0442.md

README.mediawiki

murchandamus reviewed Nov 13, 2024

View reviewed changes

moonsettler force-pushed the paircommit branch 2 times, most recently from 8f11758 to f3f7f91 Compare November 13, 2024 21:35

jonatack added the New BIP label Nov 14, 2024

moonsettler marked this pull request as ready for review November 14, 2024 15:56

murchandamus reviewed Nov 15, 2024

View reviewed changes

README.mediawiki Outdated Show resolved Hide resolved

README.mediawiki Outdated Show resolved Hide resolved

bip-PC.md Outdated Show resolved Hide resolved

moonsettler commented Nov 15, 2024

View reviewed changes

bip-PC.md Outdated Show resolved Hide resolved

moonsettler force-pushed the paircommit branch 3 times, most recently from 59249d9 to dfb0670 Compare November 15, 2024 18:24

moonsettler force-pushed the paircommit branch from dfb0670 to 92ffeb8 Compare November 23, 2024 14:51

murchandamus reviewed Nov 25, 2024

View reviewed changes

bip-PC.md Outdated Show resolved Hide resolved

bip-PC.md Outdated Show resolved Hide resolved

rot13maxi reviewed Nov 25, 2024

View reviewed changes

bip-PC.md Outdated Show resolved Hide resolved

bip-PC.md Outdated Show resolved Hide resolved

moonsettler force-pushed the paircommit branch from 2dfe8fd to bbf8c49 Compare November 25, 2024 23:01

moonsettler force-pushed the paircommit branch from 4df2a5d to 43259a7 Compare November 26, 2024 20:20

This comment was marked as off-topic.

Sign in to view

moonsettler force-pushed the paircommit branch from acc0554 to c49bc72 Compare November 27, 2024 00:43

murchandamus reviewed Dec 9, 2024

View reviewed changes

bip-PC.md Outdated Show resolved Hide resolved

bip-PC.md Outdated Show resolved Hide resolved

bip-PC.md Outdated Show resolved Hide resolved

bip-PC.md Outdated Show resolved Hide resolved

README.mediawiki Outdated Show resolved Hide resolved

moonsettler force-pushed the paircommit branch from 6e60b59 to baf6c7a Compare December 9, 2024 21:19

jonatack changed the title ~~OP_PAIRCOMMIT~~ BIP442: OP_PAIRCOMMIT Dec 17, 2024

moonsettler force-pushed the paircommit branch from f7bd2e6 to 0253838 Compare December 23, 2024 16:46

reardencode reviewed Dec 24, 2024

View reviewed changes

moonsettler force-pushed the paircommit branch 3 times, most recently from 69d8d97 to 0ad3d24 Compare December 28, 2024 17:50

murchandamus reviewed Dec 30, 2024

View reviewed changes

reardencode reviewed Dec 31, 2024

View reviewed changes

jonatack reviewed Jan 4, 2025

View reviewed changes

moonsettler marked this pull request as draft January 4, 2025 13:55

moonsettler force-pushed the paircommit branch from cfcd34e to 1a0c663 Compare February 8, 2025 18:38

murchandamus reviewed Feb 10, 2025

View reviewed changes

murchandamus added the PR Author action required Needs updates, has unaddressed review comments, or is otherwise waiting for PR author label Feb 12, 2025

murchandamus reviewed Feb 12, 2025

View reviewed changes

README.mediawiki Outdated Show resolved Hide resolved

moonsettler added 3 commits February 12, 2025 18:18

Add: PAIRCOMMIT

63296bf

New revision with Brandon Black

57df145

Fix: Authors and spelling merklize

6375ee1

moonsettler force-pushed the paircommit branch from e3ddd3f to 6375ee1 Compare February 12, 2025 17:18

Fix: header

da2b69c

	### Cost comparison of LN-Symmetry constructions
	### Weight comparison of LN-Symmetry constructions

		### Behaviors LNhance tries to avoid introducing

		The following behaviors are out of scope for LNhance and should not be enabled

		Currently, bitcoin lacks a way to hash multiple stack elements together. Which
		means building Merkle trees or verifying inclusion in a tree is not supported.

-Currently, bitcoin lacks a way to hash multiple stack elements together. Which
-means building Merkle trees or verifying inclusion in a tree is not supported.
+Currently, bitcoin lacks a way to commit to multiple stack elements together. It is common practice to hash a single item as part of a bitcoin script, either in hash/time locked contracts, or in pay-to-pubkey-hash (P2PKH) scripts, but there is no way to commit to multiple items with a single hash.
+In a contrived but demonstrative example, if PAIRCOMMIT existed in legacy script, P2PKH could be extended to pay-to-pubkey-time-hash with scriptPubKey `2DUP PAIRCOMMIT RIPEMD160 <hash> EQUALVERIFY CHECKLOCKTIMEVERIFY DROP CHECKSIG`. This script format for single signature, time-locked bitcoin could be transformed into an address format.
+With the ability to commit to pairs of elements, PAIRCOMMIT can be generalized Merklized commitments to a tree of elements with a single hash. On its own, this could enable a hash lock contract where the holder of any pre-image in a Merkle tree can unlock the spend, for example.
+If `OP_CHECKSIGFROMSTACK` is combined with PAIRCOMMIT, the ability to sign commitments to multiple items enables both of the above but as a form of delegation. In cases where any single item can be used to unlock an output, additional off chain signatures be simply can be used as an alternative to PAIRCOMMIT. However in cases where multiple items must be used for spending together, PAIRCOMMIT removes the need for complex laddering schemes to ensure that all items were authorized together.

	optimize for. Since the Tag can be pre-computed as mid-state, it would only
	optimize for. Since the tagged SHA256 hash can be pre-computed mid-state, it would only


		## Rationale

		If `OP_CAT` was available, it could be used to combine multiple stack elements

	Using in sequence `OP_CHECKTEMPLATEVERIFY`, `OP_PAIRCOMMIT`, `OP_INTERNALKEY`
	Using in sequence `OP_CHECKTEMPLATEVERIFY` (`CTV`), `OP_PAIRCOMMIT` (`PC`), `OP_INTERNALKEY` (`IK`)

	output values. This is over the practical limits to enumerate and merkelize.
	output values. This is over the practical limits to enumerate and Merklize.

	output values. This is over the practical limits to enumerate and merkelize.
	leaf scripts. This is over the practical limits to enumerate and merkelize.


		https://github.com/lnhance/bitcoin/pull/6/files

		## Rationale

BIP442: OP_PAIRCOMMIT #1699

Are you sure you want to change the base?

BIP442: OP_PAIRCOMMIT #1699

Conversation

moonsettler commented Nov 11, 2024 • edited by jonatack Loading

murchandamus left a comment

Choose a reason for hiding this comment

moonsettler commented Nov 13, 2024 • edited Loading

moonsettler commented Nov 13, 2024

jonatack commented Nov 14, 2024

murchandamus commented Nov 14, 2024

murchandamus commented Nov 14, 2024

moonsettler commented Nov 14, 2024 • edited Loading

murchandamus left a comment

Choose a reason for hiding this comment

moonsettler commented Nov 26, 2024 • edited Loading

This comment was marked as off-topic.

Ademan commented Nov 27, 2024

bigspider commented Nov 27, 2024

moonsettler commented Nov 27, 2024

Proving general computation

moonsettler commented Nov 27, 2024 • edited Loading

Ademan commented Nov 27, 2024 • edited Loading

Ademan commented Nov 27, 2024 • edited Loading

murchandamus left a comment

Choose a reason for hiding this comment

reardencode left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

JeremyRubin commented Dec 24, 2024

moonsettler commented Dec 24, 2024

JeremyRubin commented Dec 25, 2024

moonsettler commented Dec 25, 2024 • edited Loading

moonsettler commented Dec 28, 2024

Ademan commented Dec 28, 2024 • edited Loading

murchandamus left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jonatack Jan 4, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

reardencode left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jonatack left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jonatack Jan 4, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jonatack Jan 4, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

reardencode commented Jan 4, 2025

moonsettler commented Feb 8, 2025

murchandamus left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

murchandamus Feb 10, 2025 • edited Loading

moonsettler commented Nov 11, 2024 •

edited by jonatack

Loading

moonsettler commented Nov 13, 2024 •

edited

Loading

moonsettler commented Nov 14, 2024 •

edited

Loading

moonsettler commented Nov 26, 2024 •

edited

Loading

moonsettler commented Nov 27, 2024 •

edited

Loading

Ademan commented Nov 27, 2024 •

edited

Loading

Ademan commented Nov 27, 2024 •

edited

Loading

moonsettler commented Dec 25, 2024 •

edited

Loading

Ademan commented Dec 28, 2024 •

edited

Loading

jonatack Jan 4, 2025 •

edited

Loading

jonatack Jan 4, 2025 •

edited

Loading

jonatack Jan 4, 2025 •

edited

Loading

murchandamus Feb 10, 2025 •

edited

Loading