OP_PAIRCOMMIT

1 message, 15 Nov 2024. Started by moonsettler.

moonsettler

moonsettler 15 Nov 2024, 00:00 UTC permalink original

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

Quoted text (1 line)

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);

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

<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

)