|
| 1 | +``` |
| 2 | +BIP: <BIP number, or "?" before being assigned> |
| 3 | +Layer: Consensus (soft fork) |
| 4 | +Title: OP_PAIRCOMMIT |
| 5 | +Author: moonsettler <[email protected]> |
| 6 | +Comments-Summary: No comments yet. |
| 7 | +Comments-URI: <links to wiki page for comments> |
| 8 | +Status: Draft |
| 9 | +Type: Standards Track |
| 10 | +Created: 2024-11-08 |
| 11 | +License: BSD-3-CLAUSE |
| 12 | +``` |
| 13 | + |
| 14 | +## Abstract |
| 15 | + |
| 16 | +This BIP describes a new tapscript opcode `OP_PAIRCOMMIT` which |
| 17 | +provide limited vector commitment functionality in tapscript. |
| 18 | + |
| 19 | +When evaluated, the `OP_PAIRCOMMIT` instruction: |
| 20 | +* Pops the top two values off the stack, |
| 21 | +* takes the "PairCommit" tagged SHA256 hash of the stack elements, |
| 22 | +* pushes the resulting commitment on the top of the stack. |
| 23 | + |
| 24 | +## Motivation |
| 25 | + |
| 26 | +To do LN-Symmetry contracts that don't require the nodes to keep old states, |
| 27 | +we need to solve the data availability problem presented by unilateral closes. |
| 28 | +Channel peers must be able to reconstruct the script that spends an |
| 29 | +intermediate state. |
| 30 | + |
| 31 | +Using in sequence `OP_CHECKTEMPLATEVERIFY`, `OP_PAIRCOMMIT`, `OP_INTERNALKEY` |
| 32 | +and `OP_CHECKSIGFROMSTACK` we can construct a rebindable channel that is also |
| 33 | +optimal. |
| 34 | + |
| 35 | +If `OP_CAT` was available, it could be used to combine multiple stack elements, |
| 36 | +that get verified with `OP_CHECKSIGFROMSTACK` as a valid state update. |
| 37 | + |
| 38 | +`OP_PAIRCOMMIT` solves this specific problem without introducing a wide range |
| 39 | +of potentially controversial new behaviors, such as novel 2-way peg mechanisms. |
| 40 | + |
| 41 | +The number of SHA256 iterations is minimized in the primary use case we |
| 42 | +can optimize for, which is LN-Symmetry. Since the Tag can be pre-computed as |
| 43 | +mid-state, it would only take 1 or 2 hash cycles in validation for the |
| 44 | +unilateral close scenario. |
| 45 | + |
| 46 | +## Specification |
| 47 | + |
| 48 | +Repurpose opcode 205 (currently `OP_SUCCESS`) as follows: |
| 49 | + |
| 50 | +`OP_PAIRCOMMIT` pops two elements off the stack, then concatenates them along |
| 51 | +with their size commitments and takes the tagged SHA256 hash of that |
| 52 | +concatenated string, then pushes the resulting hash back on the stack. |
| 53 | + |
| 54 | +Given the stack `[x1, x2]`, where `x2` is at the top of the stack: |
| 55 | + |
| 56 | +`OP_PAIRCOMMIT` will push `SHA256(tagPC|cs(x1)|x1|cs(x2)|x2)` onto the stack. |
| 57 | + |
| 58 | +Where `|` denotes concatenation and `tagPC` is calculated according to BIP-340 |
| 59 | +tagged hash as `SHA256("PairCommit")|SHA256("PairCommit")` and `cs(x)` means |
| 60 | +`CompactSize(x)`. |
| 61 | + |
| 62 | +### Implementation |
| 63 | + |
| 64 | +```c++ |
| 65 | +case OP_PAIRCOMMIT: { |
| 66 | + // OP_PAIRCOMMIT is only available in Tapscript |
| 67 | + // ... |
| 68 | + // x1 x2 -- hash |
| 69 | + if (stack.size() < 2) { |
| 70 | + return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION); |
| 71 | + } |
| 72 | + const valtype& vch1 = stacktop(-2); |
| 73 | + const valtype& vch2 = stacktop(-1); |
| 74 | + |
| 75 | + uint256 hash = PairCommitHash(vch1, vch2); |
| 76 | + |
| 77 | + popstack(stack); |
| 78 | + popstack(stack); |
| 79 | + stack.emplace_back(hash.begin(), hash.end()); |
| 80 | + break; |
| 81 | +} |
| 82 | +``` |
| 83 | +```c++ |
| 84 | +const HashWriter HASHER_PAIRCOMMIT{TaggedHash("PairCommit")}; |
| 85 | + |
| 86 | +uint256 PairCommitHash(const std::vector<unsigned char>& x1, const std::vector<unsigned char>& x2) |
| 87 | +{ |
| 88 | + return (HashWriter{HASHER_PAIRCOMMIT} << x1 << x2).GetSHA256(); |
| 89 | +} |
| 90 | +``` |
| 91 | +### Use in script |
| 92 | +
|
| 93 | +`OP_PAIRCOMMIT` can be used to commit to a vector of stack elements in a way |
| 94 | +that is not vulnerable to various forms of witness malleability. It is however, |
| 95 | +highly optimized for just 2 stack elements. |
| 96 | +
|
| 97 | +```text |
| 98 | +# pc-hash = PC(a, PC(b, c)) |
| 99 | +
|
| 100 | +<a> <b> <c> | PC PC <pc-hash> OP_EQUALVERIFY |
| 101 | +``` |
| 102 | + |
| 103 | +### Use in LN-Symmetry |
| 104 | + |
| 105 | +The following assembly-like pseudo-code shows a possible LN-Symmetry channel |
| 106 | +construction, that provides data availability to spend to the latest state from |
| 107 | +an earlier state pushed on-chain with a forced close by channel partner. |
| 108 | + |
| 109 | + |
| 110 | +```text |
| 111 | +# S = 500000000 |
| 112 | +# IK -> A+B |
| 113 | +<sig> <state-n-recovery-data> <state-n-hash> | CTV PC IK CSFS <S+1> CLTV DROP |
| 114 | +``` |
| 115 | +before funding sign first state template: |
| 116 | +```text |
| 117 | +# state-n-hash { nLockTime(S+n), out(contract, amount(A)+amount(B)) } |
| 118 | +# settlement-n-hash { nSequence(2w), out(A, amount(A)), out(B, amount(B)) } |
| 119 | +# state-n-recovery-data { settlement-n-hash or state-n-balance } |
| 120 | +
|
| 121 | +# contract for state n < m |
| 122 | +IF |
| 123 | + <sig> <state-m-recovery-data> <state-m-hash> | CTV PC IK CSFS <S+n+1> CLTV DROP |
| 124 | +ELSE |
| 125 | + <settlement-n-hash> CTV |
| 126 | +ENDIF |
| 127 | +``` |
| 128 | + |
| 129 | +## Reference Implementation |
| 130 | + |
| 131 | +A reference implementation is provided here: |
| 132 | + |
| 133 | +https://github.com/lnhance/bitcoin/pull/6/files |
| 134 | + |
| 135 | +## Backward Compatibility |
| 136 | + |
| 137 | +By constraining the behavior of OP_SUCCESS opcodes, deployment of the BIP |
| 138 | +can be done in a backwards compatible, soft-fork manner. If anyone were to |
| 139 | +rely on the OP_SUCCESS behavior of `OP_SUCCESS205`, `OP_PAIRCOMMIT` would |
| 140 | +invalidate their spend. |
| 141 | + |
| 142 | +## Deployment |
| 143 | + |
| 144 | +TBD |
| 145 | + |
| 146 | +## Credits |
| 147 | + |
| 148 | +Jeremy Rubin, Brandon Black, Salvatore Ingala, Anthony Towns |
| 149 | + |
| 150 | +## Copyright |
| 151 | + |
| 152 | +This document is licensed under the 3-clause BSD license. |
| 153 | + |
| 154 | +## References |
| 155 | + |
| 156 | +1. LNhance bitcoin repository, [lnhance](https://github.com/lnhance/bitcoin) |
| 157 | +2. LN-Symmetry, [eltoo](https://github.com/instagibbs/bolts/blob/eltoo_draft/XX-eltoo-transactions.md) |
| 158 | +3. OP_CAT, [BIN-2024-0001](https://github.com/bitcoin-inquisition/binana/blob/master/2024/BIN-2024-0001.md) |
| 159 | +4. OP_CHECKTEMPLATEVERIFY, [BIP-119](https://github.com/bitcoin/bips/tree/master/bip-0119) |
| 160 | +5. OP_CHECKSIGFROMSTACK, [BIN-2024-0003](https://github.com/bitcoin-inquisition/binana/blob/master/2024/BIN-2024-0003.md) |
| 161 | +6. OP_INTERNALKEY, [BIN-2024-0004](https://github.com/bitcoin-inquisition/binana/blob/master/2024/BIN-2024-0004.md) |
| 162 | +7. Tagged hash, [BIP-340](https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki) |
0 commit comments