From: "'moonsettler' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
To: "bitcoindev@googlegroups.com" <bitcoindev@googlegroups.com>
Subject: [bitcoindev] OP_PAIRCOMMIT
Date: Fri, 15 Nov 2024 00:00:32 +0000 [thread overview]
Message-ID: <xyv6XTAFIPmbG1yvB0l2N3c9sWAt6lDTG-xjIbogOZ-lc9RfsFeJ-JPuXuXKzVea8T9TztlCvSrxZOWXKCwogCy9tqa49l3LXjF5K2cLtP4=@protonmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 7638 bytes --]
Hi All,
We propose to add a new opcode to tapscript, the newest member of the LNhance
opcode family, OP_PAIRCOMMIT.
LNhance is a package deal of CTV + CSFS + IKEY + PC specifically designed to
enable efficient rebindable channels, that can be grafted to a variety ofcovenant tree / channel factory constructions.
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.
https://gist.github.com/moonsettler/d7f1fb88e3e54ee7ecb6d69ff126433b
PR: 1699 to https://github.com/bitcoin/bips
Q: Why not CAT?
A: OP_PAIRCOMMIT was specifically introduced so that we don't have a dependency
on CAT for efficient LN-Symmetry construction. If we already had CAT or had
reasonable assurances that CAT will be activated soon, the balance of tradeoffs
might have tipped against a late introduction of a new opcode to a concept that
was already floating out there.
Q: What is the difference between PAIRCOMMIT and CAT?
A: PAIRCOMMIT is domain separated from other implicit uses of hashing pieces of
data together. CAT allows for reconstructing and therefore inspecting sighashes
on the stack. And not only it allows for fine grained introspection, it also
allows for inspecting ancestor transactions. This makes CAT with the Poelstra
trick a way to implement state carrying covenants.
* If CAT has consensus, PAIRCOMMIT is an optimization of which we already have
plenty examples of in script
* If CAT has no consensus, PAIRCOMMIT gets the job done in regards to a veryspecific subset of behaviors, that explicitly do not include introspection.
BR.
moonsettler
--------------------------------------------------------------------------------
<pre>
BIP: ?
Layer: Consensus (soft fork)
Title: OP_PAIRCOMMIT
Author: moonsettler <
moonsettler@protonmail•com
>
Comments-Summary: No comments yet.
Comments-URI: <links to wiki page for comments>
Status: Draft
Type: Standards Track
Created: 2024-11-08
License: BSD-3-CLAUSE
</pre>
## Abstract
This BIP describes a new tapscript opcode `OP_PAIRCOMMIT` which
provide 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.
## 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.
Channel peers must be able to reconstruct the script that spends an
intermediate state.
Using in sequence `OP_CHECKTEMPLATEVERIFY`, `OP_PAIRCOMMIT`, `OP_INTERNALKEY`
and `OP_CHECKSIGFROMSTACK` we can construct a rebindable channel that is also
optimal.
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.
`OP_PAIRCOMMIT` solves this specific problem without introducing a wide range
of potentially controversial new behaviors, such as novel 2-way peg mechanisms.
The number of SHA256 iterations is minimized in the primary use case we
can optimize for, which is LN-Symmetry. 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.
## Specification
Repurpose opcode 205 (currently `OP_SUCCESS`) as follows:
`OP_PAIRCOMMIT` pops two elements off the stack, then concatenates them along
with their size commitments and takes the tagged SHA256 hash of that
concatenated string, then pushes the resulting hash back on the stack.
Given the stack `[x1, x2]`, where `x2` is at the top of the stack:
`OP_PAIRCOMMIT` will push `SHA256(tagPC|cs(x1)|x1|cs(x2)|x2)` onto the stack.
Where `|` denotes concatenation and `tagPC` is calculated according to BIP-340
tagged hash as `SHA256("PairCommit")|SHA256("PairCommit")` and `cs(x)` means
`CompactSize(x)`.
### Implementation
```c++
case OP_PAIRCOMMIT: {
// OP_PAIRCOMMIT is only available in Tapscript
// ...
// x1 x2 -- hash
if (stack.size() < 2) {
return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
}
const valtype& vch1 = stacktop(-2);
const valtype& vch2 = stacktop(-1);
uint256 hash = PairCommitHash(vch1, vch2);
popstack(stack);
popstack(stack);
stack.emplace_back(hash.begin(), hash.end());
break;
}
```
```c++
const HashWriter HASHER_PAIRCOMMIT{TaggedHash("PairCommit")};
uint256 PairCommitHash(const std::vector<unsigned char>& x1, const std::vector<unsigned char>& x2)
{
return (HashWriter{HASHER_PAIRCOMMIT} << x1 << x2).GetSHA256();
}
```
### Use in script
`OP_PAIRCOMMIT` can be used to commit to a vector of stack elements in a way
that is not vulnerable to various forms of witness malleability. It is however,
highly optimized for just 2 stack elements.
```text
# pc-hash = PC(a, PC(b, c))
<a> <b> <c> | PC PC <pc-hash> OP_EQUALVERIFY
```
### Use in LN-Symmetry
The following assembly-like pseudo-code shows a possible LN-Symmetry channel
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.
```text
# S = 500000000
# IK -> A+B
<sig> <state-n-recovery-data> <state-n-hash> | CTV PC IK CSFS <S+1> CLTV DROP
```
before funding sign first state template:
```text
# state-n-hash { nLockTime(S+n), out(contract, amount(A)+amount(B)) }
# settlement-n-hash { nSequence(2w), out(A, amount(A)), out(B, amount(B)) }
# state-n-recovery-data { settlement-n-hash or state-n-balance }
# contract for state n < m
IF
<sig> <state-m-recovery-data> <state-m-hash> | CTV PC IK CSFS <S+n+1> CLTV DROP
ELSE
<settlement-n-hash> CTV
ENDIF
```
## Reference Implementation
A reference implementation is provided here:
https://github.com/lnhance/bitcoin/pull/6/files
## Backward Compatibility
By constraining the behavior of OP_SUCCESS opcodes, deployment of the BIP
can be done in a backwards compatible, soft-fork manner. If anyone were to
rely on the OP_SUCCESS behavior of `OP_SUCCESS205`, `OP_PAIRCOMMIT` would
invalidate their spend.
## Deployment
TBD
## Credits
Jeremy Rubin, Brandon Black, Salvatore Ingala, Anthony Towns
## Copyright
This document is licensed under the 3-clause BSD license.
## References
1. LNhance bitcoin repository, [lnhance](
https://github.com/lnhance/bitcoin
)
2. LN-Symmetry, [eltoo](
https://github.com/instagibbs/bolts/blob/eltoo_draft/XX-eltoo-transactions.md
)
3. OP_CAT, [BIN-2024-0001](
https://github.com/bitcoin-inquisition/binana/blob/master/2024/BIN-2024-0001.md
)
4. OP_CHECKTEMPLATEVERIFY, [BIP-119](
https://github.com/bitcoin/bips/tree/master/bip-0119
)
5. OP_CHECKSIGFROMSTACK, [BIN-2024-0003](
https://github.com/bitcoin-inquisition/binana/blob/master/2024/BIN-2024-0003.md
)
6. OP_INTERNALKEY, [BIN-2024-0004](
https://github.com/bitcoin-inquisition/binana/blob/master/2024/BIN-2024-0004.md
)
7. Tagged hash, [BIP-340](
https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki
)
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/xyv6XTAFIPmbG1yvB0l2N3c9sWAt6lDTG-xjIbogOZ-lc9RfsFeJ-JPuXuXKzVea8T9TztlCvSrxZOWXKCwogCy9tqa49l3LXjF5K2cLtP4%3D%40protonmail.com.
[-- Attachment #2: Type: text/html, Size: 29458 bytes --]
reply other threads:[~2024-11-15 0:03 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='xyv6XTAFIPmbG1yvB0l2N3c9sWAt6lDTG-xjIbogOZ-lc9RfsFeJ-JPuXuXKzVea8T9TztlCvSrxZOWXKCwogCy9tqa49l3LXjF5K2cLtP4=@protonmail.com' \
--to=bitcoindev@googlegroups.com \
--cc=moonsettler@protonmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox