From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 14 Nov 2024 16:03:08 -0800 Received: from mail-qt1-f186.google.com ([209.85.160.186]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tBjnn-0004fl-Rk for bitcoindev@gnusha.org; Thu, 14 Nov 2024 16:03:08 -0800 Received: by mail-qt1-f186.google.com with SMTP id d75a77b69052e-460a85907b7sf16071521cf.0 for ; Thu, 14 Nov 2024 16:03:07 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1731628982; cv=pass; d=google.com; s=arc-20240605; b=aKdsw2T9Fuel3KM1YhmEtnn5V0Pl4ZI0KGVWQ1vUCbuL1FNkyx1GR8K0Ru2npNKfYo ojS/CtLS5U3qZe46v+5m4FgwvJwis4XmU1HdE8ejXrDW9N/SzpVeL3GYQL28Oi1s6tgB 8iQE0lI/am2HfzQKE9zAtcUPfJR5WqBtx9gK2Xnr8A2ebqsECvEpIJtIj0E+EA+uUxU4 NPb1YQrj6yVP5QaqfP5AQbtz4WopYAHQCIGyGZac/58kHQfsrgMcTJJpk6caG9L2K9UX mKyZ/QrEkgllVtD89N/4xVS1y5hjGaSzq3bfL/m0SjD9s0u1zyuBsefuaHEe2BVpEm9R ayXA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:mime-version:feedback-id :message-id:subject:from:to:date:dkim-signature; bh=aFAEMHzVFLh7U9SB5pf85jX5A0D2eRlD03ejGAFNZ4M=; fh=vMjKr0jRIlQ2VgrqoX+i3qY86SO2sx/45ecreRaMsfs=; b=jBX4LPSoqcnOQONSnW7JA/mAHKUBLHguDYDjUkMD/0LlQnGwJBAPtxpwOMXrJpwhsu 7uBgQ9ioBRhRAMOWKZ78tlX4oZuwHO3sD9JPUFs8SzaJjaxPE+wjO5HD83zES3GSOiEs y+RurDBtc/scRbWGVQ8WDdJ+/LH7daTe9y6t/3TC1y6lcDc4gzU3Xl/WQccK7S/i7AJB 4jftlKdZcpiZyqaxCMAR9rnQeym8yvF74At5NkQpX3rHtbSb2dMfuNK+VAHAQ+ZQ2hta 7LzXjvmxRTmOaC/poHuT1Os3/L0MuQYRD/9lTryuT0/pZkaU4Yz3FVxJ/e/fRBATjNAN q4cA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=ngZ6sVS2; spf=pass (google.com: domain of moonsettler@protonmail.com designates 185.70.43.167 as permitted sender) smtp.mailfrom=moonsettler@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1731628982; x=1732233782; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:message-id:subject:from:to:date:from:to:cc:subject:date :message-id:reply-to; bh=aFAEMHzVFLh7U9SB5pf85jX5A0D2eRlD03ejGAFNZ4M=; b=P3zAgmiX6nt9Aobq4NPIOvQPo4uthiXkJ72MXocwSm+FR4iyGp2jNYw4dzMZH+qrLS cjhB1HtAyNQdF441i8TkWISVHhTT7Shsm1KCmQHixGy3WChhoDT1lhpZkFpT7wKuMSnT B4Ec9IlYBh+6a7O8e0os5KLW6wKUn1feRTdOvCkofIhLu+LZIzGI28579Gz+IBuLnh8a w2CVeeXYY1XTe7L/x359uEzRdglZ3fe4Uelglab9LkVtMEmx0gQ6Mkv5EOLHsKJxyoG7 jIMGM3ooWib7T/W8iR9uArGc8sRtSy2IyA5nUU6hPlsEgUiznIou9MKUox1ZAf4Y65oS NwPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731628982; x=1732233782; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:message-id:subject:from:to:date:x-beenthere :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=aFAEMHzVFLh7U9SB5pf85jX5A0D2eRlD03ejGAFNZ4M=; b=ZWbezAhuVrDN+4a6JyYYTdPtJXfJh6ozGu+clLdFSTe3w1gEWRSx7VsAk7oMHtF9wR 4KGtkGivCDzY1V/xgWIh3/M4N+YD4RYvkmJsuy5UqE/c3nNErl9czWeUEQwvuwKH2YZ2 rySLOofBPnCg+ANNJOzsVnLa/bWH5r9+k4PJevgBu476AS+vVHntbmFNltij1+liUbLc JvbaL/txBrPo4q7QPMVtGujmmQ70Zzl9uIy6Spf2ykOMuPsWjKV41gQ8P0TWtQN7B3bp X7hOuax3IjC4OnC417hraPG3vglNsQOz7Iv+uH0uCiARy7aQPBIXBkSA6rypo3GupLBp N5qg== X-Forwarded-Encrypted: i=2; AJvYcCXFDqxx/oOEiM9t6G4yljCwmy6rtA2orOSfw6QJ+w5vz48156UImmgqGcR0JFMNjuGPv8n8o3IY5Ykt@gnusha.org X-Gm-Message-State: AOJu0YyJRHshorB70/WnxfqGvgdoUPjL654U969DLis8MP/CRzzeEbIU EqB/aEw53PeXGyKUShqOIOUxUvB1z6dpnP27OqBl5gG9uySTSCrq X-Google-Smtp-Source: AGHT+IEPXnPtKtJwsiicsrPwrJOKyRyBbpa9o9JneWGh4QUfltAcz/KouHfrupzXZkjRU9IIgs+54g== X-Received: by 2002:ac8:7d82:0:b0:461:5770:cbd3 with SMTP id d75a77b69052e-46363e2db28mr8531691cf.30.1731628981645; Thu, 14 Nov 2024 16:03:01 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a05:622a:903:b0:458:355c:362b with SMTP id d75a77b69052e-46356e73ee5ls14994021cf.0.-pod-prod-06-us; Thu, 14 Nov 2024 16:02:59 -0800 (PST) X-Received: by 2002:a05:620a:17a9:b0:79f:879:63ad with SMTP id af79cd13be357-7b36235b548mr95986485a.46.1731628979317; Thu, 14 Nov 2024 16:02:59 -0800 (PST) Received: by 2002:ae9:c002:0:b0:7b1:4744:32d3 with SMTP id af79cd13be357-7b35b0a1848ms85a; Thu, 14 Nov 2024 16:00:41 -0800 (PST) X-Received: by 2002:a05:600c:6990:b0:42c:b166:913 with SMTP id 5b1f17b1804b1-432df019070mr6707935e9.11.1731628838875; Thu, 14 Nov 2024 16:00:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1731628838; cv=none; d=google.com; s=arc-20240605; b=IflK87KzI7OxHPkvY397eQZuVGJfSR+RBXSTCF/DRkEbA6iB5NQL0lXxriAXWHEmSc EVwmtf2Juud/dr4ECi/Tczj91zjxPS5ayb+Ql6AA+mhAMkQZjZwB8qRoG+KjJaa80kZd vC7fb4Q1p2djlItWoArh9oVvo7ksJugi8M+REeTvRf+qHj8sGaMyAOcpbvVb/3tBHesX A+rJXLEu+VqyTj3+KoEvHsxZWZwSOXWZbgEzOXHtfBxDd4fTLPKjgq7unSSvy7j+BSTe DfLRAt7F7BuHjrRF2ryC1pH8s5VihY7pSVHgim2ImuPhKbxURi67+D2ASKgrGiRd0b2R Ks1g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=mime-version:feedback-id:message-id:subject:from:to:date :dkim-signature; bh=erKmMRR1nwTAqjcsyznj6+i6tVkP8NQvmiQKHC+w5CU=; fh=lhFSo2W/mHC0QoJ9oNg3A35n0DTltt3CQl1/0RggJlk=; b=BsfWka6HhbL2zgCnt3KK+TJA6HAmQ9FcrGMBrdt4SWJYIpdVFyl7e2oGzP/9lnVbpV VSWlxp8bcBV+Ip1P0OD5g570nSYPq4c4Um98XFwzI1hkDKaGj90sSOXRGsB0SQZVWEkD /o2st2IYb/lwpKxzU+IZPka/KM/CBlVd/+c4YQsDWTD8dyTbrxF4kQuDxhYphxREPRED pJZwniOAK9UpD1517WF+p7/rgloJKHlEB3+eOd//yhgFRnyFlOQlwZC4C3aiNPpJGb3O Oa4uwfnLdbhOLQCJoC1BtbAcXbvnPvGijbhV7Q3Wkvnyi7hXYVGqgRJHChSyyF500SJw SXPg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=ngZ6sVS2; spf=pass (google.com: domain of moonsettler@protonmail.com designates 185.70.43.167 as permitted sender) smtp.mailfrom=moonsettler@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-43167.protonmail.ch (mail-43167.protonmail.ch. [185.70.43.167]) by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-432d478830csi2791125e9.0.2024.11.14.16.00.38 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 Nov 2024 16:00:38 -0800 (PST) Received-SPF: pass (google.com: domain of moonsettler@protonmail.com designates 185.70.43.167 as permitted sender) client-ip=185.70.43.167; Date: Fri, 15 Nov 2024 00:00:32 +0000 To: "bitcoindev@googlegroups.com" From: "'moonsettler' via Bitcoin Development Mailing List" Subject: [bitcoindev] OP_PAIRCOMMIT Message-ID: Feedback-ID: 38540639:user:proton X-Pm-Message-ID: 5ac6f399528b8132c5c46c0843c146fc39b1c03d MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1=_zaqQvmDDQHbTdw1KU4fVuG8d0QUJBATmaaN0eNsbl0" X-Original-Sender: moonsettler@protonmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=ngZ6sVS2; spf=pass (google.com: domain of moonsettler@protonmail.com designates 185.70.43.167 as permitted sender) smtp.mailfrom=moonsettler@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com X-Original-From: moonsettler Reply-To: moonsettler Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -1.0 (-) --b1=_zaqQvmDDQHbTdw1KU4fVuG8d0QUJBATmaaN0eNsbl0 Content-Type: text/plain; charset="UTF-8" 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 -------------------------------------------------------------------------------- 

BIP: ?

Layer: Consensus (soft fork)

Title: OP_PAIRCOMMIT

Author: moonsettler <

moonsettler@protonmail.com

>

Comments-Summary: No comments yet.

Comments-URI: 

Status: Draft

Type: Standards Track

Created: 2024-11-08

License: BSD-3-CLAUSE
## 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& x1, const std::vector& 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)) | PC PC 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 | CTV PC IK CSFS 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 | CTV PC IK CSFS CLTV DROP ELSE 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. --b1=_zaqQvmDDQHbTdw1KU4fVuG8d0QUJBATmaaN0eNsbl0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,<= div>
We propose to add a new opc= ode to tapscript, the newest member of the LNhance
opcode family, OP_PAIRCOMMIT.
    // x1 x2 -- hash
    if (stack.size() < 2) {
        return set= _error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
    }
    const valtype& vch1 =3D stacktop(-2);
    const valtype& vch2 = =3D stacktop(-1);

    uint256 hash =3D PairCommitHash(vch1, vch2);
=

    popstack(sta= ck);
    popstack(s= tack);
    stack.em= place_back(hash.begin(), hash.end());
    break;
}
```
```c++

uint256 PairCommitHash(co= nst std::vector<unsigned char>& x1, const std::vector<unsigned= char>& x2)
{
    return (HashWriter{HASH= ER_PAIRCOMMIT} << x1 << x2).GetSHA256();
}
```=
### Use in script

`OP_PAIRCOMMIT` can be u= sed 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 =3D PC(a, PC(b, c))

<a> <b> <c> | PC PC <pc-hash&= gt; OP_EQUALVERIFY
```=

### Use in LN-Symmet= ry

The followi= ng assembly-like pseudo-code shows a possible LN-Symmetry channel
construction, that provides data avail= ability to spend to the latest state from
an earlier state pushed on-chain with a forced close by channe= l partner.


```text
# S =3D 5= 00000000
# IK -> A+B
<sig> <state-n-recovery-d= ata> <state-n-hash> | CTV PC IK CSFS <S+1> CLTV DROP<= /div>
```
before funding sign first state template:
```text
# state-n-hash { nLockTime(S+n), out(contract, amount(A)+amount(B)) }=
# settlement-n-hash { nSeque= nce(2w), out(A, amount(A)), out(B, amount(B)) }
# state-n-recovery-data { settlement-n-hash or state-n-b= alance }

# con= tract for state n < m
IF
  <sig> <state-m= -recovery-data> <state-m-hash> | CTV PC IK CSFS <S+n+1> CLTV= DROP
ELSE
<= span style=3D"font-family: Arial, sans-serif; font-size: 14px; line-height:= normal; font-weight: 400;">  <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, dep= loyment of the BIP
can be don= e 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 license= d under the 3-clause BSD license.

## References

1. LNhance bitcoin repository, [lnhance](https://github.com/lnhance/bitcoin)
2. LN-Sym= metry, [eltoo](https://github.com/insta= gibbs/bolts/blob/eltoo_draft/XX-eltoo-transactions.md)
3. OP_CAT, [B= IN-2024-0001](https://github.com/bitcoi= n-inquisition/binana/blob/master/2024/BIN-2024-0001.md)
4. OP_CHECKT= EMPLATEVERIFY, [BIP-119](https://github= .com/bitcoin/bips/tree/master/bip-0119)=
5. OP_CHECKSIGFROMSTACK, [BI= N-2024-0003](https://github.com/bitcoin= -inquisition/binana/blob/master/2024/BIN-2024-0003.md)
6. OP_INTERNA= LKEY, [BIN-2024-0004](https://github.co= m/bitcoin-inquisition/binana/blob/master/2024/BIN-2024-0004.md)
7. Tagged= hash, [BIP-340](https://github.com/bit= coin/bips/blob/master/bip-0340.mediawiki)

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= xyv6XTAFIPmbG1yvB0l2N3c9sWAt6lDTG-xjIbogOZ-lc9RfsFeJ-JPuXuXKzVea8T9TztlCvSr= xZOWXKCwogCy9tqa49l3LXjF5K2cLtP4%3D%40protonmail.com.
--b1=_zaqQvmDDQHbTdw1KU4fVuG8d0QUJBATmaaN0eNsbl0--

LNhance is a package deal of CTV + CS= FS + IKEY + PC specifically designed to
enable efficient rebindable channels, that can be grafted to a v= ariety of
covenant tree / channel = factory constructions.

When evaluated, the `OP_PAIRCOMMIT` instruction:
* Pops the top two values off the stack,
* takes the "PairCommit" tagged SHA256 h= ash of the stack elements,
* = pushes the resulting commitment on the top of the stack.
<= br>


Q: Why not CAT?

on CAT for efficient L= N-Symmetry construction. If we already had CAT or had
reasonable assurances that CAT will be activated s= oon, the balance of tradeoffs
might have tipped against a late introduction of a new opcode to a concept= that
was already floating ou= t there.

Q: Wh= at is the difference between PAIRCOMMIT and CAT?

A: PAIRCOMMIT is domain separated from o= ther implicit uses of hashing pieces of
data together. CAT allows for reconstructing and therefore inspe= cting sighashes
on the stack.= And not only it allows for fine grained introspection, it also
allows for inspecting ancestor transacti= ons. This makes CAT with the Poelstra
trick a way to implement state carrying covenants.
* If CAT has consensus, PAIRCOMMIT is an opt= imization of which we already have
plenty examples of in script
* If CAT has no consensus, PAIRCOMMIT gets the job done in regards to= a very
specific subset of behavio= rs, that explicitly do not include introspection.

BR.
moonsettler

------= --------------------------------------------------------------------------<= /span>
<pre>
  BIP: ?
  Layer: Consensus (soft fork)
  Title: OP_PAIRCOMMIT
  Author: moonsettler <moonsettler@protonmail.com>=
;
  Comments-Summary: No=
 comments yet.
  Comment=
s-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 f=
unctionality in tapscript.

When evaluated, the `OP_PAIRCOMMIT` instruction:
<=
div>* Pops the top two values off the stack,
* takes the "PairCommit" tagge= d SHA256 hash of the stack elements,
* pushes the resulting commitment on the top of the stack.

## Motivation

To do LN-Symmetry cont= racts that don't require the nodes to keep old states,
we need to solve the data availability problem pr= esented by unilateral closes.
Channel peers must be able to reconstruct the script that spends an=
intermediate state.

Using in sequence `OP_CHECKTE= MPLATEVERIFY`, `OP_PAIRCOMMIT`, `OP_INTERNALKEY`
and `OP_CHECKSIGFROMSTACK` we can construct a rebindabl= e channel that is also
optima= l.

If `OP_CAT`= was available, it could be used to combine multiple stack elements,=
that get verified with `OP_CHECKSIG= FROMSTACK` as a valid state update.

`OP_PAIRCOMMIT` solves this specific problem without = introducing a wide range
of p= otentially 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<= /span>

Repurpose opco= de 205 (currently `OP_SUCCESS`) as follows:

`OP_PAIRCOMMIT` pops two elements off the sta= ck, then concatenates them along
with their size commitments and takes the tagged SHA256 hash of that
concatenated string, then pushe= s 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("PairComm= it")|SHA256("PairCommit")` and `cs(x)` means
`CompactSize(x)`.

### Implementation

```c++
case OP_PAIRCOMMIT: {
&n= bsp;   // OP_PAIRCOMMIT is only available in Tapscript
    // ...