-
Notifications
You must be signed in to change notification settings - Fork 5.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BIP442: OP_PAIRCOMMIT #1699
base: master
Are you sure you want to change the base?
BIP442: OP_PAIRCOMMIT #1699
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Switched back to markdown. Header now in BIP-2 format. |
8f11758
to
f3f7f91
Compare
The original create date of OP_PAIRCOMMIT is 2024-03-15 this is the latest revision based on feedback from Anthony Towns. |
Added a discussion link to the PR description.
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:
|
Has this proposal been sent to the mailing list? |
Proposed to the mailing list, waiting for feedback. |
59249d9
to
dfb0670
Compare
dfb0670
to
92ffeb8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would like to see this proposal to get more review from other covenant researchers before it moves forward.
2dfe8fd
to
bbf8c49
Compare
It looks like we gonna have to amend the Special thanks to: @JeremyRubin @Ademan @bigspider edit: |
4df2a5d
to
43259a7
Compare
acc0554
to
c49bc72
Compare
I think I've changed my mind a bit. We were talking about computing a merkle tree for 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. |
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.
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. |
Is this correct? Any suggestions? @Ademan @bigspider |
This is the main open question I believe. does it or does it not practically expand what we can already do? edit: (actually the above examples are wrong, because internally bitcoin script uses little endian, but should convey the point) |
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.
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. |
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 Bit shifts over 32 bit integers seems pretty feasible though, that's 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 |
e9540a2
to
4838e65
Compare
I think this BIP is already way more verbose than it was supposed to be. It would be useful if we could reference it by a number. |
Should we add this table to this BIP? And it's not just vBytes but also the number of sigops to consider, which is a cost all nodes on the p2p network have to bear. edit: I think it looks like this:
* VAULT is not exactly a SigOp, but close enough. Has a budget cost of 1.2 SigOps. |
tbh i have no idea how to read that table, so might be good to have clearer labeling somehow / break down where the accounting came from? |
This is based on @reardencode's spreadsheet: |
Looking at the Motivation section, it seems to me that the main application for this proposal would be a construction that depends on three other undeployed proposals some of which are themselves draft stage or pre-draft. This proposal feels a bit hypothetical at this point. I’ll get back to you next week. |
While PAIRCOMMIT would only be truly useful with certain other future upgrades, it is proposed to activate in a bundle with said updates. We are in the process of trying to reach consensus on said package. It's unlikely I would withdraw OP_PAIRCOMMIT, unless OP_CAT got activated first. |
The Created header records the date that the BIP was assigned a number (see BIP-2). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few edit suggestions on first read.
I think this can potentially be assigned a number once the BIP-2 criteria are met. A non-exhaustive list:
"When the BIP draft is complete, a BIP editor will assign the BIP a number, label it as Standards Track, Informational, or Process, and merge the pull request to the BIPs git repository.
"The BIP editors will not unreasonably reject a BIP.
"Reasons for rejecting BIPs include duplication of effort, disregard for formatting rules, being too unfocused or too broad, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the Bitcoin philosophy.
"For a BIP to be accepted it must meet certain minimum criteria.
"It must be a clear and complete description of the proposed enhancement.
"The enhancement must represent a net improvement.
"The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly."
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let’s call this BIP 442.
bip-PC.md
Outdated
|
||
### Cost comparison of LN-Symmetry constructions | ||
|
||
| Method | ChannelS | UpdateSc | UpdateWi | 1-Update | 2-Update | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The terms "ChannelS", "UpdateSc", "UpdateWi", "1-Update", and "2-Update" seem to not be defined in this document. Perhaps they should be described here to provide context, or if this is in reference to another document, that document should be linked in this section for context.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will try to figure something out, it's Channel Script, Update Script, Update Witness, total cost with 1 or 2 updates.
@reardencode?
6e60b59
to
baf6c7a
Compare
f7bd2e6
to
0253838
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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!
* takes the "PairCommit" tagged SHA256 hash of the stack elements, | ||
* pushes the resulting commitment on the top of the stack. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* takes the "PairCommit" tagged SHA256 hash of the stack elements, | |
* pushes the resulting commitment on the top of the stack. | |
* takes the "PairCommit" tagged SHA256 hash of the stack elements' lengths and values, | |
* pushes the resulting 32-byte hash to the top of the stack. |
## Motivation | ||
|
||
To do [LN-Symmetry] contracts that don't require the nodes to keep old states, | ||
we need to solve the data availability problem presented by unilateral closes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While this was the original motivation for developing PAIRCOMMIT, I don't think it's the current motivation for introducing it standalone, or including it in LNHANCE.
Perhaps something more like:
When building scripts using
OP_CHECKSIGFROMSTACK
, it is common to require a commitment to multiple items in a specific sequence and without malleability.OP_PAIRCOMMIT
enables efficient commitments of this type. Alternative methods for achieving these multiple commitments require an additional signature checking operation for each additional unordered commitment or 2 additional signature checks for each additional ordered commitment.One example of such a construction is [LN-Symmetry] which requires a single signature to commit both to the update CTV hash and the settlement CTV hash to ensure O(1) data storage requirements for each channel partner. Another is a complex delegation (delegating to various pubkeys after matching locktimes). Either of these contracts can be achieved without
OP_PAIRCOMMIT
but they would require the use of a costlyOP_RETURN
or 2 additional signature checks respectively.
Then (as we discussed) move the remaining symmetry discussion to its own section.
|
||
Where `|` denotes concatenation and `tagPC` is calculated according to | ||
[BIP-340] tagged hash as `SHA256("PairCommit")|SHA256("PairCommit")` and | ||
`cs(x)` means `CompactSize(x)`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where is CompactSize
defined?
## Rationale | ||
|
||
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add
Using
OP_CAT
for this purpose requires additional opcodes to prevent malleability (e.g.0x0102 0x03 CAT
is identical to0x01 0x0203 CAT
).
or similar.
`OP_PAIRCOMMIT` solves this specific problem without introducing a wide range | ||
of potentially controversial new behaviors, such as novel 2-way peg mechanisms. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
`OP_PAIRCOMMIT` solves this specific problem without introducing a wide range | |
of potentially controversial new behaviors, such as novel 2-way peg mechanisms. | |
`OP_PAIRCOMMIT` solves this specific problem without introducing granular introspection | |
via Andrew Poelstra's CAT and Schnorr Tricks. |
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this section belong in the PC BIP?
There are practical limits to the entropy space for the *inputs* as they need | ||
to be iterated over and hashed into a merkle root. | ||
|
||
MAST trees can currently cover 128 bits of entropy space, which is well over |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
MAST -> Taproot?
to be iterated over and hashed into a merkle root. | ||
|
||
MAST trees can currently cover 128 bits of entropy space, which is well over | ||
the practical limits to iterate over and merklize. Therefore, we assume this |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
assume -> conclude
the practical limits to iterate over and merklize. Therefore, we assume this | ||
capability does not materially extend what computations are possible to prove | ||
in bitcoin script. While `OP_PAIRCOMMIT` is not limited to a height of 128, | ||
that should not be practically feasible to utilize. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should not be -> is
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 computation, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I find this paragraph confusing. I think a variant of it probably belongs in the CHECKSIGFROMSTACK BIP - as CSFS can be used generally to sign data into a script and that is not limited to use with PC (although PC extends that capability to merkelized data).
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
this works because while the first commit commits to either 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. |
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