path: root/66/568fe179fe746f737ecde8115278c27b801877

Return-Path: <gsanders87@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 219FAC0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 22 Aug 2023 19:22:35 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id DCB8F400D2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 22 Aug 2023 19:22:34 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org DCB8F400D2
Authentication-Results: smtp2.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20221208 header.b=sjHGR6f1
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level: 
X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
 FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id d28pKYYZkSNB
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 22 Aug 2023 19:22:33 +0000 (UTC)
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com
 [IPv6:2a00:1450:4864:20::631])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 80688403AC
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 22 Aug 2023 19:22:32 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 80688403AC
Received: by mail-ej1-x631.google.com with SMTP id
 a640c23a62f3a-99d937b83efso625737566b.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 22 Aug 2023 12:22:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20221208; t=1692732150; x=1693336950;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :from:to:cc:subject:date:message-id:reply-to;
 bh=bK3rC03CR/qEtj1XiYfcjt4dPDj3XCRGYaCNNwVO8aM=;
 b=sjHGR6f1TeQREn7FfzBPdcy/OhEExxyjucUZQty4bcUeQIvInJroaCJq9AQUeM1ZoF
 TSpPsJHUur1pHZ718nQcV85Q6AT0xc2FczF1+OMufYFnGDt3uuPtJkI7zJ+jqjPr2JSi
 26iDE8NqRbaAyST43jLl+6Xb3FPGSQLdovUdE4hpMItAyDsGrsV3BiddYK+gQSYM1/wu
 RbVIOa+4+PihmIKzxhc+ZDZyS6ZgdAeSq3MlxfmZ+M2F9x9L7q2GMp+Lz+7OYMf3ILcH
 UZmPO4K+thAgxL8pbf0Cmq6DNyQG9sfS8ENWVyycM2YJOKitSZ0iaZKUpwOdbddnffd2
 TAOQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1692732150; x=1693336950;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
 bh=bK3rC03CR/qEtj1XiYfcjt4dPDj3XCRGYaCNNwVO8aM=;
 b=QX5t58RtOWVGACYiczGXJ+4LtDIpHBda8NDCY8+qLRIiOhpi2U4nUohh77CTtIoIWP
 Oh8zbbqntQHI9GCWX54svXAPfJBxhlGp+PQLku8IKcYMSptO1/vOxPUFDsj/PAv+6bbx
 WfUGvOtu1j6rmc3Kffpd/WY2v3i0OCnk/zMWpndlH1t0C2UiTF5LrzbMBHvysqJOiEAr
 phUgaE8ojsJJPNJwldGzhGHQCERgQ/Rs8Q3VHerxOV9F0WurEul086GLpNbp6q+1RS8n
 ZQhd1GVeZmTTvf4cgTWpgkVEopOXsWkD68U3S+ehhQJyVRlMPJi2bSrL0oWJeAMKhdXS
 vLOQ==
X-Gm-Message-State: AOJu0Yzwt3KdPaWP1gjIuefSs/VFb1sJQdqH9IHGw27/vBexfKo50Imy
 nrN6j0fB6Y/PYOP12D2fXzBuckiOBqNRpZ/xl9H6z/+GVkY=
X-Google-Smtp-Source: AGHT+IEwcWzkIfdC1Iz6hfBGUV64znAGURduckkuHHz6XL97qKWqCSRrFTecZwwpL0qLtIErWnjhlpaTSgd6eOtmfBQ=
X-Received: by 2002:a17:906:cc2:b0:99d:f560:5d3c with SMTP id
 l2-20020a1709060cc200b0099df5605d3cmr9026417ejh.23.1692732150151; Tue, 22 Aug
 2023 12:22:30 -0700 (PDT)
MIME-Version: 1.0
References: <ZOTqppwATA9HyfND@console>
In-Reply-To: <ZOTqppwATA9HyfND@console>
From: Greg Sanders <gsanders87@gmail.com>
Date: Tue, 22 Aug 2023 15:22:18 -0400
Message-ID: <CAB3F3Dvhp-Zznd0USWW=sWh7AFL4OV3KneWTgdqZu5Z1BYYJKg@mail.gmail.com>
To: Brandon Black <freedom@reardencode.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000828034060387ea10"
Subject: Re: [bitcoin-dev] Combined CTV+APO to minimal TXHASH+CSFS
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Aug 2023 19:22:35 -0000

--000000000000828034060387ea10
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Brandon,

Not going to dive too deep here, just adding a bit of color.

> * If the top item on the stack is not a minimally encoded `OP_0`, `OP_1`,
or
  `OP_2`; succeed immediately[^2].

I presume this was supposed to go to OP_4 now.

> ### How does the efficiency compare to [bip118][]?

Just noting BIP118 also allows pubkey of "1" to stand in for the taproot
inner pubkey, which would be a common use-case. "simply" adding an opcode
ala OP_INNER_PUBKEY could also have the same effect of course.

Also, BIP118 also opens the door for non-APO signatures to have a sighash
digest that commits to additional data, closing a couple of taproot
malleability bugs. See
https://github.com/bitcoin-inquisition/bitcoin/issues/19 for more
discussion along those lines. These aren't make or break, but would be nice
to clean up if possible

Best,
Greg

On Tue, Aug 22, 2023 at 3:04=E2=80=AFPM Brandon Black via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi list,
>
> https://gist.github.com/reardencode/2aa98700b720174598d21989dd46e781
>
> I'm seeking feedback on this proposal to provide the functionality
> requested by those advocating for bip118 and bip119 in a combined way
> that retains the low risk associated with each of those separate
> proposals. At least part of the reason for creating this is similar to
> my reason for creating bips PR#1472, and my covenant comparo
> spreadsheet, i.e. to help further the discussion of these proposals and
> make more clear the similarities and differences between them.
>
> https://github.com/bitcoin/bips/pull/1472
>
> https://docs.google.com/spreadsheets/d/1YL5ttNb6-SHS6-C8-1tHwao1_19zNQ-31=
YWPAHDZgfo/edit
>
> It's become clear to me that in large part the separation between
> advocates of these two proposals stems from a lack of full understanding
> of their properties. My hope is that this work helps to clarify our
> thinking about them individually and together, and potentially move
> toward consensus on a path toward enabling better lightning, vaults, and
> likely other amazing ways to use bitcoin in the future.
>
> -----------------------
>
> # Abstract
>
> This proposal is an alternative to [bip119][] and [bip118][], providing t=
he
> functionality of both proposals with no additional overhead in [many
> cases](#compared-to-non-tapscript-ctv), while clearing certain objections
> to
> both, and opening clear upgrade paths.
>
> This is, in essence, an initially constrained version of Russel O'Connor'=
s
> [OP_TXHASH+OP_CSFS proposal][].
>
> We define three new Tapscript-only opcodes. Replacing `OP_SUCCESS80`,
> `OP_SUCCESS187`, and `OP_SUCCESS188` with `OP_TXHASH`,
> `OP_CHECKSIGFROMSTACK`,
> and `OP_CHECKSIGFROMSTACKVERIFY` respectively.
>
> # Summary
>
> For `OP_TXHASH`, we define exactly 5 methods of hashing the transaction
> depending
> on a minimally encoded numeric argument popped from the stack:
>
> argument | behavior
> -------- | -----------------
>    0     | as in [bip119][]
>    1     | as in [bip118][] with sighash flag `0x41`
>    2     | as in [bip118][] with sighash flag `0xc1`
>    3     | as in [bip118][] with sighash flag `0x43`
>    4     | as in [bip118][] with sighash flag `0xc3`
>
> `OP_CHECKSIGFROMSTACK(VERIFY)` is defined similarly to the [implementatio=
n
> in
> the Elements project][OP_CHECKSIGFROMSTACK in elements], but does not
> internally SHA256 hash the data argument. As [bip340][] defines signature=
s
> on
> arbitrary length messages, and these `OP_CHECKSIGFROMSTACK(VERIFY)` are
> defined only in Tapscript, the internal hashing is unnecessarily
> restrictive.
> Users may wish to use pre-hashed values as in this proposal, or non-SHA25=
6
> hashes available in script.
>
> # Motivation
>
> Much ink has been spilled on the discussion of what is next for bitcoin
> scipt
> development. The two proposals nearest to consensus are [bip118][] and
> [bip119][], but the proponents of each disagree about the relative priori=
ty
> and the merrits of the other. Here, we'll briefly outline some of the
> objections to each and demonstrate how this proposal reduces those
> objections.
> We will not discuss the concerns about the introduction of covenants or
> recursive covenants generally.
>
> ## [CTV][bip119] Objections
>
> * Not general enough
> * Inefficient when otherwise validating the hash (e.g. when combined with
>   `OP_CHECKSIGFROMSTACK`)
> * Uses `OP_NOPx` extension semantics even though `OP_SUCCESSx` is availab=
le
>
> ## [APO][bip118] Objections
>
> * Not general enough
> * Accidentally enables inefficient, hard to use covenants
> * Uses new Tapscript key version to avoid accidents
>
> ## Solutions
>
> * By providing the behavior of both [bip118][] and [bip119][], this
> proposal
>   is more general than either of those proposals. It also provides explic=
it
>   upgrade hooks for further generality (e.g. to
>   [full OP_TXHASH][OP_TXHASH+OP_CSFS proposal]).
> * By splitting the hashing from the validation of [bip119], the hash can =
be
>   used in ways other than `OP_EQUALVERIFY`.
> * We use `OP_SUCCESSx` upgrade semantics.
> * We explicitly enable some of the sighash-based covenants accidentally
>   enabled by [bip118][].
> * By using new signature checking opcodes, we do not require the safety o=
f
> a
>   new Tapscript key version.
>
> # Specification
>
> ## `OP_TXHASH`
>
> When validating Tapscript, the behavior of `OP_SUCCESS80` is modified as
> follows:
> * If there is not at least one item on the stack, fail[^1].
> * If the top item on the stack is not a minimally encoded `OP_0`, `OP_1`,
> or
>   `OP_2`; succeed immediately[^2].
> * Pop the top item from the stack, and name it `hash_mode`
> * If `hash_mode` is 0:
>     * Hash the transaction as defined in [bip119][]
>     * Push the resulting hash to the stack
> * If `hash_mode` is 1:
>     * Hash the transaction as defined in [bip118][] using
> `sighash_type=3D0x41`
>     * Push the resulting hash to the stack
> * If `hash_mode` is 2:
>     * Hash the transaction as defined in [bip118][] using
> `sighash_type=3D0xc1`
>     * Push the resulting hash to the stack
> * If `hash_mode` is 3:
>     * Hash the transaction as defined in [bip118][] using
> `sighash_type=3D0x43`
>     * Push the resulting hash to the stack
> * If `hash_mode` is 4:
>     * Hash the transaction as defined in [bip118][] using
> `sighash_type=3D0xc3`
>     * Push the resulting hash to the stack
>
> ## `OP_CHECKSIGFROMSTACK(VERIFY)`
>
> When validating Tapscript, the behavior of `OP_SUCCESS187` and
> `OP_SUCCESS188`
> are modified as follows:
> * If there are not at least 3 items on the stack, fail[^1].
> * If the top-minus-0 stack item's length is not 32, succeed
> immediately[^2].
> * If the top-minus-2 stack item's length is not 64, fail[^3].
> * Pop the top 3 stack items as `pubkey`, `msg`, and `sig` respectively.
> * Let `result` equal the result of verifying `sig` against `msg` and
> `pubkey` according to [bip340][].
> * Push `true` if `result` otherwise `false` to the stack.
> * If validating `OP_CHECKSIGFROMSTACKVERIFY`
>     * Pop the top item from the stack as `check`.
>     * If `check` is not `true`, fail.
>
> # Discussion
>
> ### How does the efficiency compare to [bip118][]?
>
> `SIGHASH_ANYPREVOUT`:
> ```
> <64-byte signature>||<1-byte sighash type> <33-byte pubkey>
> OP_CHECKSIG(VERIFY)
> with pushes: 64+1+1 + 33+1 + 1 =3D 101 witness bytes (25.25vBytes)
> ```
>
> This proposal:
> ```
> <64-byte signature> <1-byte argument> OP_TXHASH <32-byte pubkey>
> OP_CHECKSIGFROMSTACK(VERIFY)
> with pushes: 64+1 + 1 + 1 + 32+1 + 1 =3D 101 witness bytes (25.25vBytes)
> ```
>
> ### How does the efficiency compare to [bip119][]?
>
> #### Both in Tapscript
>
> `OP_CHECKTEMPLATEVERIFY` alone:
> ```
> <32-byte hash> OP_CHECKTEMPLATEVERIFY OP_DROP OP_TRUE
> with pushes: 32+1 + 1 + 1 + 1 =3D 36 witness bytes (9vBytes)
> ```
>
> `OP_CHECKTEMPLATEVERIFY` with a subsequent check:
> ```
> <32-byte hash> OP_CHECKTEMPLATEVERIFY OP_DROP <...>
> with pushes: 32+1 + 1 + 1 =3D 35 witness bytes (8.75vBytes)
> ```
>
> This proposal:
> ```
> <1-byte argument> OP_TXHASH <32-byte hash> OP_EQUAL(VERIFY)
> with pushes: 1 + 1 + 32+1 + 1 =3D 36 witness bytes (9 vBytes)
> ```
>
> #### Compared to non-Tapscript CTV
>
> Bare `OP_CHECKTEMPLATEVERIFY`:
> ```
> Lock: <32-byte hash> OP_CHECKTEMPLATEVERIFY OP_DROP OP_TRUE
> with pushes: 32+1 + 1 + 1 + 1 =3D 36 bytes (36vBytes)
>
> Unlock: <empty>
>
> Total: 36 + 0 =3D 36vBytes
> ```
>
> Witness v0 CTV:
> ```
> Lock: OP_0 <32-byte hash>
> with pushes: 1 + 32+1 =3D 34 bytes (34 vBytes)
>
> Unlock:
> <36-byte witness script>
> with sizes: 36+1 =3D 37 witness bytes (9.25vBytes)
>
> Total: 34 + 9.25 =3D 43.25vBytes
> ```
>
> This proposal:
> ```
> Lock: OP_1 <32-byte pubkey>
> with pushes: 1 + 32+1 =3D 34 bytes (34 vBytes)
>
> Unlock:
> <36-byte leaf script> <33-byte control block>
> with sizes: 36+1 + 33+1 =3D 71 witness bytes (17.75vBytes)
>
> Total: 34 + 17.75 =3D 51.75vBytes
> ```
>
> Compared to bare CTV, this proposal is 15.75vBytes more costly. If CTV us=
e
> cases gain popularity, a separate upgrade for bare CTV may be warranted,
> either as specified in [bip119][], as its own witness version, or some
> alternative.
>
> Bearing in mind the risks mentioned in [bip119][], fee sensitive users ca=
n
> add
> `OP_RIPEMD160` to save 2.75 vBytes when using `OP_TXHASH` with
> `OP_EQUAL(VERIFY)`. This brings the excess cost relative to bare CTV down
> to
> 13vBytes.
>
> ### Why not include modes for [bip118][] sighash_types 0x42 and 0xc2?[^4]
>
> Possibly due to a lack of imagination, we are unable to see a use for
> signing
> none of the inputs and none of the outputs (or a single input script and
> none
> of the outputs).
>
> ### Can this be used in ln-symmetry?
>
> Yes, this is fully compatible with ln-symmetry. It uses a different scrip=
t,
> but has the same size and behavior as [bip118][] for this purpose.
>
> ### Can this be used in PTLCs?
>
> Yes, this is fully compatible with PTLCs. It uses a different script, but
> has
> the same size and behavior as [bip118][] for this purpose.
>
> ### Can this be used with OP_VAULT?
>
> Yes, this is fully compatible with OP_VAULT. It uses a different script,
> but
> has the same size and behavior as [bip119][] for this purpose.
>
> # What is hashed?
>
> | field \ mode                        | CTV(0) | APO/ALL(1) | APOAS/ALL(2=
)
> | APO/SINGLE(3) | APOAS/SINGLE(4) |
> | ----------------------------------- | ------ | ---------- | -----------=
-
> | ------------- | --------------- |
> | hash_type                           |        | x          | x
> | x             | x               |
> | version/locktime                    | x      | x          | x
> | x             | x               |
> | this input UTXO                     |        |            |
> |               |                 |
> | other input UTXOs                   |        |            |
> |               |                 |
> | this script pubkey/amount           |        | x          |
> | x             |                 |
> | other script pubkeys/amounts        |        |            |
> |               |                 |
> | this script sig                     | x      |            |
> |               |                 |
> | other script sig                    | x      |            |
> |               |                 |
> | the number of inputs                | x      |            |
> |               |                 |
> | this input sequence                 | x      | x          | x
> | x             | x               |
> | other input sequences               | x      |            |
> |               |                 |
> | this input spend type/annex         |        | x          | x
> | x             | x               |
> | other input spend types/annexes     |        |            |
> |               |                 |
> | corresponding output script/amount  | x      | x          | x
> | x             | x               |
> | other output scripts/amounts        | x      | x          | x
> |               |                 |
> | the number of outputs               | x      |            |
> |               |                 |
>
> # Notes
>
> [^1]: We fail on invalid stack lengths to ensure that attackers cannot sk=
ip
>   validation.
> [^2]: We succeed on unspecified txhash modes or pubkey lengths to allow
> future
>   extensions.
> [^3]: We fail on invalid signature lengths _after_ the pubkey length chec=
k,
>   thus allowing only 64-byte signatures for 32-byte keys, but allowing
> future
>   key types to potentially also have different signature lengths.
> [^4]: As far as we know there is no use for sighash types other than thos=
e
>   defined in [bip118][] with this proposal, as the other types either
> reduce
>   to `OP_CHECKSIG(VERIFY)` or create infinite hash loops.
>
> [bip118]: https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki
> [bip119
> <https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki%5Bbip119>=
]:
> https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki
> [bip340
> <https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki%5Bbip340>=
]:
> https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki
> [OP_TXHASH+OP_CSFS proposal]:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/0198=
13.html
> [OP_CHECKSIGFROMSTACK in elements]:
> https://github.com/ElementsProject/elements/blob/f08447909101bfbbcaf89e38=
2f55c87b2086198a/src/script/interpreter.cpp#L1399
> [proposed ln-symmetry scripts]:
> https://github.com/instagibbs/bolts/blob/eltoo_draft/XX-eltoo-transaction=
s.md
>
> -----------------------
>
> Best,
>
> --Brandon
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--000000000000828034060387ea10
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi Brandon,</div><div><br></div><div>Not going to div=
e too deep here, just adding a bit of color.</div><div><br></div><div>&gt; =
* If the top item on the stack is not a minimally encoded `OP_0`, `OP_1`, o=
r<br></div>=C2=A0 `OP_2`; succeed immediately[^2].<div><br></div><div>I pre=
sume this was supposed to go to OP_4 now.<br><div><br></div>&gt; ### How do=
es the efficiency compare to [bip118][]?<div><br></div><div>Just noting BIP=
118 also allows pubkey of &quot;1&quot; to stand in for the taproot inner p=
ubkey, which would be a common use-case. &quot;simply&quot; adding an opcod=
e ala OP_INNER_PUBKEY could also have the same effect of course.<br></div><=
div><br></div><div>Also, BIP118 also opens the door for non-APO signatures =
to have a sighash digest that commits to additional data, closing a couple =
of taproot malleability bugs. See=C2=A0<a href=3D"https://github.com/bitcoi=
n-inquisition/bitcoin/issues/19">https://github.com/bitcoin-inquisition/bit=
coin/issues/19</a> for more discussion along those lines. These aren&#39;t =
make or break, but would be nice to clean up if possible</div><div><br></di=
v><div>Best,</div><div>Greg</div></div></div><br><div class=3D"gmail_quote"=
><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Aug 22, 2023 at 3:04=E2=80=
=AFPM Brandon Black via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists=
.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi list,<br>
<br>
<a href=3D"https://gist.github.com/reardencode/2aa98700b720174598d21989dd46=
e781" rel=3D"noreferrer" target=3D"_blank">https://gist.github.com/reardenc=
ode/2aa98700b720174598d21989dd46e781</a><br>
<br>
I&#39;m seeking feedback on this proposal to provide the functionality<br>
requested by those advocating for bip118 and bip119 in a combined way<br>
that retains the low risk associated with each of those separate<br>
proposals. At least part of the reason for creating this is similar to<br>
my reason for creating bips PR#1472, and my covenant comparo<br>
spreadsheet, i.e. to help further the discussion of these proposals and<br>
make more clear the similarities and differences between them.<br>
<br>
<a href=3D"https://github.com/bitcoin/bips/pull/1472" rel=3D"noreferrer" ta=
rget=3D"_blank">https://github.com/bitcoin/bips/pull/1472</a><br>
<a href=3D"https://docs.google.com/spreadsheets/d/1YL5ttNb6-SHS6-C8-1tHwao1=
_19zNQ-31YWPAHDZgfo/edit" rel=3D"noreferrer" target=3D"_blank">https://docs=
.google.com/spreadsheets/d/1YL5ttNb6-SHS6-C8-1tHwao1_19zNQ-31YWPAHDZgfo/edi=
t</a><br>
<br>
It&#39;s become clear to me that in large part the separation between<br>
advocates of these two proposals stems from a lack of full understanding<br=
>
of their properties. My hope is that this work helps to clarify our<br>
thinking about them individually and together, and potentially move<br>
toward consensus on a path toward enabling better lightning, vaults, and<br=
>
likely other amazing ways to use bitcoin in the future.<br>
<br>
-----------------------<br>
<br>
# Abstract<br>
<br>
This proposal is an alternative to [bip119][] and [bip118][], providing the=
<br>
functionality of both proposals with no additional overhead in [many<br>
cases](#compared-to-non-tapscript-ctv), while clearing certain objections t=
o<br>
both, and opening clear upgrade paths.<br>
<br>
This is, in essence, an initially constrained version of Russel O&#39;Conno=
r&#39;s<br>
[OP_TXHASH+OP_CSFS proposal][].<br>
<br>
We define three new Tapscript-only opcodes. Replacing `OP_SUCCESS80`,<br>
`OP_SUCCESS187`, and `OP_SUCCESS188` with `OP_TXHASH`, `OP_CHECKSIGFROMSTAC=
K`,<br>
and `OP_CHECKSIGFROMSTACKVERIFY` respectively.<br>
<br>
# Summary<br>
<br>
For `OP_TXHASH`, we define exactly 5 methods of hashing the transaction dep=
ending<br>
on a minimally encoded numeric argument popped from the stack:<br>
<br>
argument | behavior<br>
-------- | -----------------<br>
=C2=A0 =C2=A00=C2=A0 =C2=A0 =C2=A0| as in [bip119][]<br>
=C2=A0 =C2=A01=C2=A0 =C2=A0 =C2=A0| as in [bip118][] with sighash flag `0x4=
1`<br>
=C2=A0 =C2=A02=C2=A0 =C2=A0 =C2=A0| as in [bip118][] with sighash flag `0xc=
1`<br>
=C2=A0 =C2=A03=C2=A0 =C2=A0 =C2=A0| as in [bip118][] with sighash flag `0x4=
3`<br>
=C2=A0 =C2=A04=C2=A0 =C2=A0 =C2=A0| as in [bip118][] with sighash flag `0xc=
3`<br>
<br>
`OP_CHECKSIGFROMSTACK(VERIFY)` is defined similarly to the [implementation =
in<br>
the Elements project][OP_CHECKSIGFROMSTACK in elements], but does not<br>
internally SHA256 hash the data argument. As [bip340][] defines signatures =
on<br>
arbitrary length messages, and these `OP_CHECKSIGFROMSTACK(VERIFY)` are<br>
defined only in Tapscript, the internal hashing is unnecessarily restrictiv=
e.<br>
Users may wish to use pre-hashed values as in this proposal, or non-SHA256<=
br>
hashes available in script.<br>
<br>
# Motivation<br>
<br>
Much ink has been spilled on the discussion of what is next for bitcoin sci=
pt<br>
development. The two proposals nearest to consensus are [bip118][] and<br>
[bip119][], but the proponents of each disagree about the relative priority=
<br>
and the merrits of the other. Here, we&#39;ll briefly outline some of the<b=
r>
objections to each and demonstrate how this proposal reduces those objectio=
ns.<br>
We will not discuss the concerns about the introduction of covenants or<br>
recursive covenants generally.<br>
<br>
## [CTV][bip119] Objections<br>
<br>
* Not general enough<br>
* Inefficient when otherwise validating the hash (e.g. when combined with<b=
r>
=C2=A0 `OP_CHECKSIGFROMSTACK`)<br>
* Uses `OP_NOPx` extension semantics even though `OP_SUCCESSx` is available=
<br>
<br>
## [APO][bip118] Objections<br>
<br>
* Not general enough<br>
* Accidentally enables inefficient, hard to use covenants<br>
* Uses new Tapscript key version to avoid accidents<br>
<br>
## Solutions<br>
<br>
* By providing the behavior of both [bip118][] and [bip119][], this proposa=
l<br>
=C2=A0 is more general than either of those proposals. It also provides exp=
licit<br>
=C2=A0 upgrade hooks for further generality (e.g. to<br>
=C2=A0 [full OP_TXHASH][OP_TXHASH+OP_CSFS proposal]).<br>
* By splitting the hashing from the validation of [bip119], the hash can be=
<br>
=C2=A0 used in ways other than `OP_EQUALVERIFY`.<br>
* We use `OP_SUCCESSx` upgrade semantics.<br>
* We explicitly enable some of the sighash-based covenants accidentally<br>
=C2=A0 enabled by [bip118][].<br>
* By using new signature checking opcodes, we do not require the safety of =
a<br>
=C2=A0 new Tapscript key version.<br>
<br>
# Specification<br>
<br>
## `OP_TXHASH`<br>
<br>
When validating Tapscript, the behavior of `OP_SUCCESS80` is modified as<br=
>
follows:<br>
* If there is not at least one item on the stack, fail[^1].<br>
* If the top item on the stack is not a minimally encoded `OP_0`, `OP_1`, o=
r<br>
=C2=A0 `OP_2`; succeed immediately[^2].<br>
* Pop the top item from the stack, and name it `hash_mode`<br>
* If `hash_mode` is 0:<br>
=C2=A0 =C2=A0 * Hash the transaction as defined in [bip119][]<br>
=C2=A0 =C2=A0 * Push the resulting hash to the stack<br>
* If `hash_mode` is 1:<br>
=C2=A0 =C2=A0 * Hash the transaction as defined in [bip118][] using `sighas=
h_type=3D0x41`<br>
=C2=A0 =C2=A0 * Push the resulting hash to the stack<br>
* If `hash_mode` is 2:<br>
=C2=A0 =C2=A0 * Hash the transaction as defined in [bip118][] using `sighas=
h_type=3D0xc1`<br>
=C2=A0 =C2=A0 * Push the resulting hash to the stack<br>
* If `hash_mode` is 3:<br>
=C2=A0 =C2=A0 * Hash the transaction as defined in [bip118][] using `sighas=
h_type=3D0x43`<br>
=C2=A0 =C2=A0 * Push the resulting hash to the stack<br>
* If `hash_mode` is 4:<br>
=C2=A0 =C2=A0 * Hash the transaction as defined in [bip118][] using `sighas=
h_type=3D0xc3`<br>
=C2=A0 =C2=A0 * Push the resulting hash to the stack<br>
<br>
## `OP_CHECKSIGFROMSTACK(VERIFY)`<br>
<br>
When validating Tapscript, the behavior of `OP_SUCCESS187` and `OP_SUCCESS1=
88`<br>
are modified as follows:<br>
* If there are not at least 3 items on the stack, fail[^1].<br>
* If the top-minus-0 stack item&#39;s length is not 32, succeed immediately=
[^2].<br>
* If the top-minus-2 stack item&#39;s length is not 64, fail[^3].<br>
* Pop the top 3 stack items as `pubkey`, `msg`, and `sig` respectively.<br>
* Let `result` equal the result of verifying `sig` against `msg` and `pubke=
y` according to [bip340][].<br>
* Push `true` if `result` otherwise `false` to the stack.<br>
* If validating `OP_CHECKSIGFROMSTACKVERIFY`<br>
=C2=A0 =C2=A0 * Pop the top item from the stack as `check`.<br>
=C2=A0 =C2=A0 * If `check` is not `true`, fail.<br>
<br>
# Discussion<br>
<br>
### How does the efficiency compare to [bip118][]?<br>
<br>
`SIGHASH_ANYPREVOUT`:<br>
```<br>
&lt;64-byte signature&gt;||&lt;1-byte sighash type&gt; &lt;33-byte pubkey&g=
t; OP_CHECKSIG(VERIFY)<br>
with pushes: 64+1+1 + 33+1 + 1 =3D 101 witness bytes (25.25vBytes)<br>
```<br>
<br>
This proposal:<br>
```<br>
&lt;64-byte signature&gt; &lt;1-byte argument&gt; OP_TXHASH &lt;32-byte pub=
key&gt; OP_CHECKSIGFROMSTACK(VERIFY)<br>
with pushes: 64+1 + 1 + 1 + 32+1 + 1 =3D 101 witness bytes (25.25vBytes)<br=
>
```<br>
<br>
### How does the efficiency compare to [bip119][]?<br>
<br>
#### Both in Tapscript<br>
<br>
`OP_CHECKTEMPLATEVERIFY` alone:<br>
```<br>
&lt;32-byte hash&gt; OP_CHECKTEMPLATEVERIFY OP_DROP OP_TRUE<br>
with pushes: 32+1 + 1 + 1 + 1 =3D 36 witness bytes (9vBytes)<br>
```<br>
<br>
`OP_CHECKTEMPLATEVERIFY` with a subsequent check:<br>
```<br>
&lt;32-byte hash&gt; OP_CHECKTEMPLATEVERIFY OP_DROP &lt;...&gt;<br>
with pushes: 32+1 + 1 + 1 =3D 35 witness bytes (8.75vBytes)<br>
```<br>
<br>
This proposal:<br>
```<br>
&lt;1-byte argument&gt; OP_TXHASH &lt;32-byte hash&gt; OP_EQUAL(VERIFY)<br>
with pushes: 1 + 1 + 32+1 + 1 =3D 36 witness bytes (9 vBytes)<br>
```<br>
<br>
#### Compared to non-Tapscript CTV<br>
<br>
Bare `OP_CHECKTEMPLATEVERIFY`:<br>
```<br>
Lock: &lt;32-byte hash&gt; OP_CHECKTEMPLATEVERIFY OP_DROP OP_TRUE<br>
with pushes: 32+1 + 1 + 1 + 1 =3D 36 bytes (36vBytes)<br>
<br>
Unlock: &lt;empty&gt;<br>
<br>
Total: 36 + 0 =3D 36vBytes<br>
```<br>
<br>
Witness v0 CTV:<br>
```<br>
Lock: OP_0 &lt;32-byte hash&gt;<br>
with pushes: 1 + 32+1 =3D 34 bytes (34 vBytes)<br>
<br>
Unlock:<br>
&lt;36-byte witness script&gt;<br>
with sizes: 36+1 =3D 37 witness bytes (9.25vBytes)<br>
<br>
Total: 34 + 9.25 =3D 43.25vBytes<br>
```<br>
<br>
This proposal:<br>
```<br>
Lock: OP_1 &lt;32-byte pubkey&gt;<br>
with pushes: 1 + 32+1 =3D 34 bytes (34 vBytes)<br>
<br>
Unlock:<br>
&lt;36-byte leaf script&gt; &lt;33-byte control block&gt;<br>
with sizes: 36+1 + 33+1 =3D 71 witness bytes (17.75vBytes)<br>
<br>
Total: 34 + 17.75 =3D 51.75vBytes<br>
```<br>
<br>
Compared to bare CTV, this proposal is 15.75vBytes more costly. If CTV use<=
br>
cases gain popularity, a separate upgrade for bare CTV may be warranted,<br=
>
either as specified in [bip119][], as its own witness version, or some<br>
alternative.<br>
<br>
Bearing in mind the risks mentioned in [bip119][], fee sensitive users can =
add<br>
`OP_RIPEMD160` to save 2.75 vBytes when using `OP_TXHASH` with<br>
`OP_EQUAL(VERIFY)`. This brings the excess cost relative to bare CTV down t=
o<br>
13vBytes.<br>
<br>
### Why not include modes for [bip118][] sighash_types 0x42 and 0xc2?[^4]<b=
r>
<br>
Possibly due to a lack of imagination, we are unable to see a use for signi=
ng<br>
none of the inputs and none of the outputs (or a single input script and no=
ne<br>
of the outputs).<br>
<br>
### Can this be used in ln-symmetry?<br>
<br>
Yes, this is fully compatible with ln-symmetry. It uses a different script,=
<br>
but has the same size and behavior as [bip118][] for this purpose.<br>
<br>
### Can this be used in PTLCs?<br>
<br>
Yes, this is fully compatible with PTLCs. It uses a different script, but h=
as<br>
the same size and behavior as [bip118][] for this purpose.<br>
<br>
### Can this be used with OP_VAULT?<br>
<br>
Yes, this is fully compatible with OP_VAULT. It uses a different script, bu=
t<br>
has the same size and behavior as [bip119][] for this purpose.<br>
<br>
# What is hashed?<br>
<br>
| field \ mode=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 | CTV(0) | APO/ALL(1) | APOAS/ALL(2) | APO/SINGLE(=
3) | APOAS/SINGLE(4) |<br>
| ----------------------------------- | ------ | ---------- | ------------ =
| ------------- | --------------- |<br>
| hash_type=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 | x=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 | x=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =
x=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| x=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br>
| version/locktime=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 | x=C2=A0 =C2=A0 =C2=A0 | x=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 | x=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | x=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0| x=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0|<br>
| this input UTXO=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br>
| other input UTXOs=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br>
| this script pubkey/amount=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0=
 =C2=A0 =C2=A0 =C2=A0 | x=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | x=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0|<br>
| other script pubkeys/amounts=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0|<br>
| this script sig=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0| x=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br>
| other script sig=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 | x=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0|<br>
| the number of inputs=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | x=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0|<br>
| this input sequence=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0| x=C2=A0 =C2=A0 =C2=A0 | x=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | x=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | x=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0| x=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0|<br>
| other input sequences=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0| x=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0|<br>
| this input spend type/annex=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 | x=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | x=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 | x=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0| x=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br>
| other input spend types/annexes=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br>
| corresponding output script/amount=C2=A0 | x=C2=A0 =C2=A0 =C2=A0 | x=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | x=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | x=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| x=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br>
| other output scripts/amounts=C2=A0 =C2=A0 =C2=A0 =C2=A0 | x=C2=A0 =C2=A0 =
=C2=A0 | x=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | x=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br>
| the number of outputs=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0| x=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0|<br>
<br>
# Notes<br>
<br>
[^1]: We fail on invalid stack lengths to ensure that attackers cannot skip=
<br>
=C2=A0 validation.<br>
[^2]: We succeed on unspecified txhash modes or pubkey lengths to allow fut=
ure<br>
=C2=A0 extensions.<br>
[^3]: We fail on invalid signature lengths _after_ the pubkey length check,=
<br>
=C2=A0 thus allowing only 64-byte signatures for 32-byte keys, but allowing=
 future<br>
=C2=A0 key types to potentially also have different signature lengths.<br>
[^4]: As far as we know there is no use for sighash types other than those<=
br>
=C2=A0 defined in [bip118][] with this proposal, as the other types either =
reduce<br>
=C2=A0 to `OP_CHECKSIG(VERIFY)` or create infinite hash loops.<br>
<br>
[bip118]: <a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0118.m=
ediawiki%5Bbip119" rel=3D"noreferrer" target=3D"_blank">https://github.com/=
bitcoin/bips/blob/master/bip-0118.mediawiki<br>
[bip119</a>]: <a href=3D"https://github.com/bitcoin/bips/blob/master/bip-01=
19.mediawiki%5Bbip340" rel=3D"noreferrer" target=3D"_blank">https://github.=
com/bitcoin/bips/blob/master/bip-0119.mediawiki<br>
[bip340</a>]: <a href=3D"https://github.com/bitcoin/bips/blob/master/bip-03=
40.mediawiki" rel=3D"noreferrer" target=3D"_blank">https://github.com/bitco=
in/bips/blob/master/bip-0340.mediawiki</a><br>
[OP_TXHASH+OP_CSFS proposal]: <a href=3D"https://lists.linuxfoundation.org/=
pipermail/bitcoin-dev/2022-January/019813.html" rel=3D"noreferrer" target=
=3D"_blank">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-Ja=
nuary/019813.html</a><br>
[OP_CHECKSIGFROMSTACK in elements]: <a href=3D"https://github.com/ElementsP=
roject/elements/blob/f08447909101bfbbcaf89e382f55c87b2086198a/src/script/in=
terpreter.cpp#L1399" rel=3D"noreferrer" target=3D"_blank">https://github.co=
m/ElementsProject/elements/blob/f08447909101bfbbcaf89e382f55c87b2086198a/sr=
c/script/interpreter.cpp#L1399</a><br>
[proposed ln-symmetry scripts]: <a href=3D"https://github.com/instagibbs/bo=
lts/blob/eltoo_draft/XX-eltoo-transactions.md" rel=3D"noreferrer" target=3D=
"_blank">https://github.com/instagibbs/bolts/blob/eltoo_draft/XX-eltoo-tran=
sactions.md</a><br>
<br>
-----------------------<br>
<br>
Best,<br>
<br>
--Brandon<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000828034060387ea10--