path: root/78/779924892ff075a098855d0e35bf4d8b6ef2ea

Return-Path: <roconnor@blockstream.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 48C4AC000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  8 Feb 2022 02:16:27 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 19C2D40126
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  8 Feb 2022 02:16:27 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key)
 header.d=blockstream-com.20210112.gappssmtp.com
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 VBeRO19Dq6lc
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  8 Feb 2022 02:16:24 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com
 [IPv6:2607:f8b0:4864:20::836])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 3BCFC400D3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  8 Feb 2022 02:16:24 +0000 (UTC)
Received: by mail-qt1-x836.google.com with SMTP id t1so7651432qtq.13
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 07 Feb 2022 18:16:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=blockstream-com.20210112.gappssmtp.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=/qZQSYLWuW8vIPto5gVy1ooU2diuztG6qqCbiMevMBg=;
 b=T3+pITD2qOCqdmuxtXLBnhIhY3Dg+VLLNeBpQ7KFNhhCj91+3fTM9/RFIaFxrvy4vw
 kbi3S3ZFJtc7hgkLDRuV0D+mSBwGes22AHytiH8eTQy8vR8KaPwx4xok6XSEXhzXqXvi
 +Ct3AOjqVZLzXkqjOHaY7epkGh79l2iXhsk6B0umhkHrqV4vCXJ8uAhR9kKnFthshTvK
 7Gu/vwWKrNczDHFvwUneE6QVQZTFlFpQfG+u08NbqF3CBQs5UZEZjjT881qctsvxmTNJ
 EIrSic46PytaCB1kAgJOFL0viebDiw7gGGnnWqCKK5HjicaZhPLgY6eUzFJqMXPJFnYR
 BXEg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to;
 bh=/qZQSYLWuW8vIPto5gVy1ooU2diuztG6qqCbiMevMBg=;
 b=s7x4NUOPvU4UbBY2eSRYs3BSPSb9NW2s65F2S3+me3Pog72ejIrANet6g/1BHv5A83
 s//bDb986jVJHnaSF6In5+jGkaLtYF4bNAA2WykWU5Q+SNuUhx8INUgCl1G9Ke6l6SPf
 6Lgb4GjKakV8MqS1/8ol39C2i6CcfG6QUPz0qu64N3PDjzJEijtw8Hsa/H/U3RtN46WP
 lF0fiIhiaEiirVTi+SDW0yyphsABXwQaa7JFMxmYkvo+XKH4GfkvY0MXi7aMDM5CTGhy
 Rbk+bS4QHXB1Eiwgdt+fb0yh0geevr0PYn7yoLFjvoZ4LRG4WABVOnS+HcJo9NTwdD25
 qzOg==
X-Gm-Message-State: AOAM5321dBW4jtJYeJdd2qBYRA6NFB1JRBLmut2JvHNdagXtQKunhlyS
 zKIMAVe/ypBkXKgARhUtNUPZuF9Cjn61nykBp4FAXlPxHoPvXA==
X-Google-Smtp-Source: ABdhPJzMgcByOlF++kSQBfGLi+KqXmE2EKZpJUbfkv0zpv5vC9YBumSY+oEWQDVMF+zzu27eUGB2qOwlyGE9Y5HmQWI=
X-Received: by 2002:a05:622a:192:: with SMTP id
 s18mr1676907qtw.268.1644286582506; 
 Mon, 07 Feb 2022 18:16:22 -0800 (PST)
MIME-Version: 1.0
References: <CAMZUoK=pkZuovtifBzdqhoyegzG+9hRTFEc7fG9nZPDK4KbU3w@mail.gmail.com>
 <20220128013436.GA2939@erisian.com.au>
 <CAMZUoK=U_-ah3cQbESE8hBXOvSMpxJJd1-ca0mYo7SvMi7izYQ@mail.gmail.com>
 <20220201011639.GA4317@erisian.com.au>
In-Reply-To: <20220201011639.GA4317@erisian.com.au>
From: "Russell O'Connor" <roconnor@blockstream.com>
Date: Mon, 7 Feb 2022 21:16:10 -0500
Message-ID: <CAMZUoKmp_B9vYX8akyWz6dXtrx6PWfDV6mDVG5Nk2MZdoAqnAg@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000a8d80a05d7784da1"
Subject: Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV
	and ANYPREVOUT
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, 08 Feb 2022 02:16:27 -0000

--000000000000a8d80a05d7784da1
Content-Type: text/plain; charset="UTF-8"

On Mon, Jan 31, 2022 at 8:16 PM Anthony Towns <aj@erisian.com.au> wrote:

> On Fri, Jan 28, 2022 at 08:56:25AM -0500, Russell O'Connor via bitcoin-dev
> wrote:
> > >
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019243.html
> > For more complex interactions, I was imagining combining this TXHASH
> > proposal with CAT and/or rolling SHA256 opcodes.  If TXHASH ended up
> > supporting relative or absolute input/output indexes then users could
> > assemble the hashes of the particular inputs and outputs they care about
> > into a single signed message.
>
> That's certainly possible, but it sure seems overly complicated and
> error prone...
>

Indeed, and we really want something that can be programmed at redemption
time.
That probably involves something like how the historic MULTISIG worked by
having list of input / output indexes be passed in along with length
arguments.

I don't think there will be problems with quadratic hashing here because as
more inputs are list, the witness in turns grows larger itself.  The amount
of stack elements that can be copied is limited by a constant (3DUP).
Certainly care is needed here, but also keep in mind that an OP_HASH256
does a double hash and costs one weight unit.

That said, your SIGHASH_GROUP proposal suggests that some sort of
intra-input communication is really needed, and that is something I would
need to think about.

While normally I'd be hesitant about this sort of feature creep, when we
are talking about doing soft-forks, I really think it makes sense to think
through these sorts of issues (as we are doing here).


> > I don't think there is much in the way of lessons to be drawn from how we
> > see Bitcoin Script used today with regards to programs built out of
> > reusable components.
>
> I guess I think one conclusion we should draw is some modesty in how
> good we are at creating general reusable components. That is, bitcoin
> script looks a lot like a relatively general expression language,
> that should allow you to write interesting things; but in practice a
> lot of it was buggy (OP_VER hardforks and resource exhaustion issues),
> or not powerful enough to actually be interesting, or too complicated
> to actually get enough use out of [0].
>

> TXHASH + CSFSV won't be enough by itself to allow for very interesting
> > programs Bitcoin Script yet, we still need CAT and friends for that,
>
> "CAT" and "CHECKSIGFROMSTACK" are both things that have been available in
> elements for a while; has anyone managed to build anything interesting
> with them in practice, or are they only useful for thought experiments
> and blog posts? To me, that suggests that while they're useful for
> theoretical discussion, they don't turn out to be a good design in
> practice.
>

Perhaps the lesson to be drawn is that languages should support multiplying
two numbers together.

Having 2/3rd of the language you need to write interesting programs doesn't
mean that you get 2/3rd of the interesting programs written.

But beyond that, there is a lot more to a smart contract than just the
Script.  Dmitry Petukhov has a fleshed out design for Asset based lending
on liquid at https://ruggedbytes.com/articles/ll/, despite the limitations
of (pre-taproot) Elements Script.  But to make it a real thing you need
infrastructure for working with partial transactions, key management, etc.

> but
> > CSFSV is at least a step in that direction.  CSFSV can take arbitrary
> > messages and these messages can be fixed strings, or they can be hashes
> of
> > strings (that need to be revealed), or they can be hashes returned from
> > TXHASH, or they can be locktime values, or they can be values that are
> > added or subtracted from locktime values, or they can be values used for
> > thresholds, or they can be other pubkeys for delegation purposes, or they
> > can be other signatures ... for who knows what purpose.
>
> I mean, if you can't even think of a couple of uses, that doesn't seem
> very interesting to pursue in the near term? CTV has something like half
> a dozen fairly near-term use cases, but obviously those can all be done
> just with TXHASH without a need for CSFS, and likewise all the ANYPREVOUT
> things can obviously be done via CHECKSIG without either TXHASH or CSFS...
>
> To me, the point of having CSFS (as opposed to CHECKSIG) seems to be
> verifying that an oracle asserted something; but for really simply boolean
> decisions, doing that via a DLC seems better in general since that moves
> more of the work off-chain; and for the case where the signature is being
> used to authenticate input into the script rather than just gating a path,
> that feels a bit like a weaker version of graftroot?
>

I didn't really mean this as a list of applications; it was a list of
values that CSFSV composes with. Applications include delegation of pubkeys
and oracles, and, in the presence of CAT and transaction reflection
primitives, presumably many more things.


> I guess I'd still be interested in the answer to:
>
> > > If we had CTV, POP_SIGDATA, and SIGHASH_NO_TX_DATA_AT_ALL but no
> OP_CAT,
> > > are there any practical use cases that wouldn't be covered that having
> > > TXHASH/CAT/CHECKSIGFROMSTACK instead would allow? Or where those would
> > > be significantly more convenient/efficient?
> > >
> > > (Assume "y x POP_SIGDATA POP_SIGDATA p CHECKSIGVERIFY q CHECKSIG"
> > > commits to a vector [x,y] via p but does not commit to either via q so
> > > that there's some "CAT"-like behaviour available)
>

I don't know if this is the answer you are looking for, but technically
TXHASH + CAT + SHA256 awkwardly gives you limited transaction reflection.
In fact, you might not even need TXHASH, though it certainly helps.


> TXHASH seems to me to be clearly the more flexible opcode compared to
> CTV; but maybe all that flexibility is wasted, and all the real use
> cases actually just want CHECKSIG or CTV? I'd feel much better having
> some idea of what the advantage of being flexible there is...
>

The flexibility of TXHASH is intended to head off the need for future soft
forks.  If we had specific applications in mind, we could simply set up the
transaction hash flags to cover all the applications we know about.  But it
is the applications that we don't know about that worry me.  If we don't
put options in place with this soft-fork proposal, then they will need
their own soft-fork down the line; and the next application after that, and
so on.

If our attitude is to craft our soft-forks as narrowly as possible to limit
them to what only allows for given tasks, then we are going to end up
needing a lot more soft-forks, and that is not a good outcome.

But all that aside, probably the real question is can we simplify CTV's
> transaction message algorithm, if we assume APO is enabled simultaneously?
> If it doesn't get simplified and needs its own hashing algorithm anyway,
> that would be probably be a good reason to keep the separate.
>
> First, since ANYPREVOUT commits to the scriptPubKey, you'd need to use
> ANYPREVOUTANYSCRIPT for CTV-like behaviour.
>
> ANYPRVOUTANYSCRIPT is specced as commiting to:
>   nVersion
>   nLockTime
>   nSequence
>   spend_type and annex present
>   sha_annex (if present)
>   sha_outputs (ALL) or sha_single_output (SINGLE)
>   key_version
>   codesep_pos
>
> CTV commits to:
>   nVersion
>   nLockTime
>   scriptSig hash "(maybe!)"
>   input count
>   sequences hash
>   output count
>   outputs hash
>   input index
>
> (CTV thus allows annex malleability, since it neither commits to the
> annex nor forbids inclusion of an annex)
>
> "output count" and "outputs index" would both be covered by sha_outputs
> with ANYPREVOUTANYSCRIPT|ALL.
>
> I think "scriptSig hash" is only covered to avoid txid malleability; but
> just adjusting your protocol to use APO signatures instead of relying on
> the txid of future transactions also solves that problem.
>
> I believe "sequences hash", "input count" and "input index" are all an
> important part of ensuring that if you have two UTXOs distributing 0.42
> BTC to the same set of addresses via CTV, that you can't combine them in a
> single transaction and end up sending losing one of the UTXOs to fees. I
> don't believe there's a way to resolve that with bip 118 alone, however
> that does seem to be a similar problem to the one that SIGHASH_GROUP
> tries to solve.
>

It was my understanding that it is only "input count = 1" that prevents
this issue.

SIGHASH_GROUP [1] would be an alternative to ALL/SINGLE/NONE, with the exact
> group of outputs being committed to determined via the annex.
> ANYPREVOUTANYSCRIPT|GROUP would commit to:
>
>   nVersion
>   nLockTime
>   nSequence
>   spend_type and annex present
>   sha_annex (if present)
>   sha_group_outputs (GROUP)
>   key_version
>   codesep_pos
>
> So in that case if you have your two inputs:
>
>   0.42 [pays 0.21 to A, 0.10 to B, 0.10 to C]
>   0.42 [pays 0.21 to A, 0.10 to B, 0.10 to C]
>
> then, either:
>
>   a) if they're both committed with GROUP and sig_group_count = 3, then
>      the outputs must be [0.21 A, 0.10 B, 0.10 C, 0.21 A, 0.10 B, 0.10
>      C], and you don't lose funds
>
>   b) if they're both committed with GROUP and the first is
>      sig_group_count=3 and the second is sig_group_count=0, then the
>      outputs can be [0.21 A, 0.10 B, 0.10 C, *anything] -- but in that
>      case the second input is already signalling that it's meant to be
>      paired with another input to fund the same three outputs, so any
>      funds loss is at least intentional
>
> Note that this means txids are very unstable: if a tx is only protected
> by SIGHASH_GROUP commitments then miners/relayers can add outputs, or
> reorganise the groups without making the tx invalid. Beyond requiring
> the signatures to be APO/APOAS-based to deal with that, we'd also need
> to avoid txs getting rbf-pinned by some malicious third party who pulls
> apart the groups and assembles a new tx that's hard to rbf but also
> unlikely to confirm due to having a low feerate.
>
> Note also that not reusing addresses solves this case -- it's only a
> problem when you're paying the same amounts to the same addresses.
>
> Being able to combine additional inputs and outputs at a later date
> (which necessarily changes the txid) is an advantage though: it lets
> you add additional funds and claim change, which allows you to adjust
> to different fee rates.
>
> I don't think the SIGHASH_GROUP approach would work very well without
> access to the annex, ie if you're trying to do CTV encoded either in a
> plain scriptPubKey or via segwit/p2sh.
>
> I think that would give 16 different sighashes, choosing one of four
> options for outputs,
>
>  ALL/NONE/SINGLE/GROUP
>    -- which outputs are committed to
>
> and one of four options for inputs,
>
>  -/ANYONECANPAY/ANYPREVOUT/ANYPREVOUTANYSCRIPT
>    -- all inputs committed to, specific input committed to,
>       scriptpubkey/tapscript committed to, or just the
>       nseq/annex/codesep_pos
>
> vs the ~155,000 sighashes in the TXHASH proposal.
>
> I don't think there's an efficient way of doing SIGHASH_GROUP via tx
> introspection opcodes that doesn't also introduce a quadratic hashing
> risk -- you need to prevent different inputs from re-hashing distinct but
> overlapping sets of outputs, and if your opcodes only allow grabbing one
> output at a time to add to the message being signed you have to do a lot
> of coding if you want to let the signer choose how many outputs to commit
> to; if you provide an opcode that grabs man outputs to hash, it seems
> hard to do that generically in a way that avoids quadratic behaviour.
>
> So I think that suggests two alternative approaches, beyond the
> VERIFY-vs-PUSH semantic:
>
>  - have a dedicated sighash type for CTV (either an explicit one for it,
>    per bip119, or support thousands of options like the proposal in this
>    thread, one of which happens to be about the same as the bip119 idea)
>
>  - use ANYPREVOUTANYSCRIPT|GROUP for CTV, which means also implementing
>    annex parsing and better RBF behaviour to avoid those txs being
>    excessively vulnerable to pinning; with the advantage being that
>    txs using "GROUP" sigs can be combined either for batching purposes
>    or for adapting to the fee market after the signature has been made,
>    and the disadvantage that you can't rely on stable txids when looking
>    for CTV spends and have to continue using APO/APOAS when chaining
>    signatures on top of unconfirmed CTV outputs
>
> Cheers,
> aj
>
> [0] Here's bitmatrix trying to multiply two numbers together:
>
> https://medium.com/bit-matrix/technical-how-does-bitmatrix-v1-multiply-two-integers-in-the-absence-of-op-mul-a58b7a3794a3
>
>     Likewise, doing a point preimage reveal via clever scripting
>     pre-taproot never saw an implementation, despite seeming
>     theoretically plausible.
>
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-November/000344.html
>
> [1]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019243.html
>
>

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

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail=
_attr">On Mon, Jan 31, 2022 at 8:16 PM Anthony Towns &lt;<a href=3D"mailto:=
aj@erisian.com.au">aj@erisian.com.au</a>&gt; wrote:<br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid=
 rgb(204,204,204);padding-left:1ex">On Fri, Jan 28, 2022 at 08:56:25AM -050=
0, Russell O&#39;Connor via bitcoin-dev wrote:<br>
&gt; &gt; <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-de=
v/2021-July/019243.html" rel=3D"noreferrer" target=3D"_blank">https://lists=
.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019243.html</a><br>
&gt; For more complex interactions, I was imagining combining this TXHASH<b=
r>
&gt; proposal with CAT and/or rolling SHA256 opcodes.=C2=A0 If TXHASH ended=
 up<br>
&gt; supporting relative or absolute input/output indexes then users could<=
br>
&gt; assemble the hashes of the particular inputs and outputs they care abo=
ut<br>
&gt; into a single signed message.<br>
<br>
That&#39;s certainly possible, but it sure seems overly complicated and<br>
error prone...<br></blockquote><div><br></div><div>Indeed, and we really wa=
nt something that can be programmed at redemption time.</div><div>That prob=
ably involves something like how the historic MULTISIG worked by having lis=
t of input / output indexes be passed in along with length arguments.</div>=
<div><br></div><div>I don&#39;t think there will be problems with quadratic=
 hashing here because as more inputs are list, the witness in turns grows l=
arger itself.=C2=A0 The amount of stack elements that can be copied is limi=
ted by a constant (3DUP).=C2=A0 Certainly care is needed here, but also kee=
p in mind that an OP_HASH256 does a double hash and costs one weight unit.<=
/div><div><br></div><div>That said, your SIGHASH_GROUP proposal suggests th=
at some sort of intra-input communication is really needed, and that is som=
ething I would need to think about.<br></div><div><br></div><div>While norm=
ally I&#39;d be hesitant about this sort of feature creep, when we are talk=
ing about doing soft-forks, I really think it makes sense to think through =
these sorts of issues (as we are doing here).<br></div><div>=C2=A0<br></div=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex">
&gt; I don&#39;t think there is much in the way of lessons to be drawn from=
 how we<br>
&gt; see Bitcoin Script used today with regards to programs built out of<br=
>
&gt; reusable components.<br>
<br>
I guess I think one conclusion we should draw is some modesty in how<br>
good we are at creating general reusable components. That is, bitcoin<br>
script looks a lot like a relatively general expression language,<br>
that should allow you to write interesting things; but in practice a<br>
lot of it was buggy (OP_VER hardforks and resource exhaustion issues),<br>
or not powerful enough to actually be interesting, or too complicated<br>
to actually get enough use out of [0].<br></blockquote><div><br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex">
&gt; TXHASH + CSFSV won&#39;t be enough by itself to allow for very interes=
ting<br>
&gt; programs Bitcoin Script yet, we still need CAT and friends for that,<b=
r>
<br>
&quot;CAT&quot; and &quot;CHECKSIGFROMSTACK&quot; are both things that have=
 been available in<br>
elements for a while; has anyone managed to build anything interesting<br>
with them in practice, or are they only useful for thought experiments<br>
and blog posts? To me, that suggests that while they&#39;re useful for<br>
theoretical discussion, they don&#39;t turn out to be a good design in<br>
practice.<br></blockquote><div><br></div><div>Perhaps the lesson to be draw=
n is that languages should support multiplying two numbers together.</div><=
div><br></div><div>Having 2/3rd of the language you need to write interesti=
ng programs doesn&#39;t mean that you get 2/3rd of the interesting programs=
 written.</div><div><br></div><div>But beyond that, there is a lot more to =
a smart contract than just the Script.=C2=A0 Dmitry Petukhov has a fleshed =
out design for Asset based lending on liquid at <a href=3D"https://ruggedby=
tes.com/articles/ll/">https://ruggedbytes.com/articles/ll/</a>, despite the=
 limitations of (pre-taproot) Elements Script.=C2=A0 But to make it a real =
thing you need infrastructure for working with partial transactions, key ma=
nagement, etc.<br></div><div><br></div><div></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex">
&gt; but<br>
&gt; CSFSV is at least a step in that direction.=C2=A0 CSFSV can take arbit=
rary<br>
&gt; messages and these messages can be fixed strings, or they can be hashe=
s of<br>
&gt; strings (that need to be revealed), or they can be hashes returned fro=
m<br>
&gt; TXHASH, or they can be locktime values, or they can be values that are=
<br>
&gt; added or subtracted from locktime values, or they can be values used f=
or<br>
&gt; thresholds, or they can be other pubkeys for delegation purposes, or t=
hey<br>
&gt; can be other signatures ... for who knows what purpose.<br>
<br>
I mean, if you can&#39;t even think of a couple of uses, that doesn&#39;t s=
eem<br>
very interesting to pursue in the near term? CTV has something like half<br=
>
a dozen fairly near-term use cases, but obviously those can all be done<br>
just with TXHASH without a need for CSFS, and likewise all the ANYPREVOUT<b=
r>
things can obviously be done via CHECKSIG without either TXHASH or CSFS...<=
br>
<br>
To me, the point of having CSFS (as opposed to CHECKSIG) seems to be<br>
verifying that an oracle asserted something; but for really simply boolean<=
br>
decisions, doing that via a DLC seems better in general since that moves<br=
>
more of the work off-chain; and for the case where the signature is being<b=
r>
used to authenticate input into the script rather than just gating a path,<=
br>
that feels a bit like a weaker version of graftroot?<br></blockquote><div><=
br></div><div>I didn&#39;t really mean this as a list of applications; it w=
as a list of values that CSFSV composes with. Applications include delegati=
on of pubkeys and oracles, and, in the presence of CAT and transaction refl=
ection primitives, presumably many more things.</div><div>=C2=A0</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex">
I guess I&#39;d still be interested in the answer to:<br>
<br>
&gt; &gt; If we had CTV, POP_SIGDATA, and SIGHASH_NO_TX_DATA_AT_ALL but no =
OP_CAT,<br>
&gt; &gt; are there any practical use cases that wouldn&#39;t be covered th=
at having<br>
&gt; &gt; TXHASH/CAT/CHECKSIGFROMSTACK instead would allow? Or where those =
would<br>
&gt; &gt; be significantly more convenient/efficient?<br>
&gt; &gt; <br>
&gt; &gt; (Assume &quot;y x POP_SIGDATA POP_SIGDATA p CHECKSIGVERIFY q CHEC=
KSIG&quot;<br>
&gt; &gt; commits to a vector [x,y] via p but does not commit to either via=
 q so<br>
&gt; &gt; that there&#39;s some &quot;CAT&quot;-like behaviour available)<b=
r></blockquote><div><br></div><div>I don&#39;t know if this is the answer y=
ou are looking for, but technically TXHASH=C2=A0+ CAT + SHA256 awkwardly gi=
ves you limited transaction reflection.=C2=A0 In fact, you might not even n=
eed TXHASH, though it certainly helps. <br></div><div>=C2=A0<br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex">
TXHASH seems to me to be clearly the more flexible opcode compared to<br>
CTV; but maybe all that flexibility is wasted, and all the real use<br>
cases actually just want CHECKSIG or CTV? I&#39;d feel much better having<b=
r>
some idea of what the advantage of being flexible there is...<br></blockquo=
te><div><br></div><div>The flexibility of TXHASH is intended to head off th=
e need for future soft forks.=C2=A0 If we had specific applications in mind=
, we could simply set up the transaction hash flags to cover all the applic=
ations we know about.=C2=A0 But it is the applications that we don&#39;t kn=
ow about that worry me.=C2=A0 If we don&#39;t put options in place with thi=
s soft-fork proposal, then they will need their own soft-fork down the line=
; and the next application after that, and so on.<br></div><div>=C2=A0</div=
><div>If our attitude is to craft our soft-forks as narrowly as possible to=
 limit them to what only allows for given tasks, then we are going to end u=
p needing a lot more soft-forks, and that is not a good outcome.</div><div>=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
But all that aside, probably the real question is can we simplify CTV&#39;s=
<br>
transaction message algorithm, if we assume APO is enabled simultaneously?<=
br>
If it doesn&#39;t get simplified and needs its own hashing algorithm anyway=
,<br>
that would be probably be a good reason to keep the separate.<br>
<br>
First, since ANYPREVOUT commits to the scriptPubKey, you&#39;d need to use<=
br>
ANYPREVOUTANYSCRIPT for CTV-like behaviour.<br>
<br>
ANYPRVOUTANYSCRIPT is specced as commiting to:<br>
=C2=A0 nVersion<br>
=C2=A0 nLockTime<br>
=C2=A0 nSequence<br>
=C2=A0 spend_type and annex present<br>
=C2=A0 sha_annex (if present)<br>
=C2=A0 sha_outputs (ALL) or sha_single_output (SINGLE)<br>
=C2=A0 key_version<br>
=C2=A0 codesep_pos<br>
<br>
CTV commits to:<br>
=C2=A0 nVersion<br>
=C2=A0 nLockTime<br>
=C2=A0 scriptSig hash &quot;(maybe!)&quot;<br>
=C2=A0 input count<br>
=C2=A0 sequences hash<br>
=C2=A0 output count<br>
=C2=A0 outputs hash<br>
=C2=A0 input index<br>
<br>
(CTV thus allows annex malleability, since it neither commits to the<br>
annex nor forbids inclusion of an annex)<br>
<br>
&quot;output count&quot; and &quot;outputs index&quot; would both be covere=
d by sha_outputs<br>
with ANYPREVOUTANYSCRIPT|ALL.<br>
<br>
I think &quot;scriptSig hash&quot; is only covered to avoid txid malleabili=
ty; but<br>
just adjusting your protocol to use APO signatures instead of relying on<br=
>
the txid of future transactions also solves that problem.<br>
<br>
I believe &quot;sequences hash&quot;, &quot;input count&quot; and &quot;inp=
ut index&quot; are all an<br>
important part of ensuring that if you have two UTXOs distributing 0.42<br>
BTC to the same set of addresses via CTV, that you can&#39;t combine them i=
n a<br>
single transaction and end up sending losing one of the UTXOs to fees. I<br=
>
don&#39;t believe there&#39;s a way to resolve that with bip 118 alone, how=
ever<br>
that does seem to be a similar problem to the one that SIGHASH_GROUP<br>
tries to solve.<br></blockquote><div><br></div><div>It was my understanding=
 that it is only &quot;input count =3D 1&quot; that prevents this issue.</d=
iv><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
SIGHASH_GROUP [1] would be an alternative to ALL/SINGLE/NONE, with the exac=
t<br>
group of outputs being committed to determined via the annex.<br>
ANYPREVOUTANYSCRIPT|GROUP would commit to:<br>
<br>
=C2=A0 nVersion<br>
=C2=A0 nLockTime<br>
=C2=A0 nSequence<br>
=C2=A0 spend_type and annex present<br>
=C2=A0 sha_annex (if present)<br>
=C2=A0 sha_group_outputs (GROUP)<br>
=C2=A0 key_version<br>
=C2=A0 codesep_pos<br>
<br>
So in that case if you have your two inputs:<br>
<br>
=C2=A0 0.42 [pays 0.21 to A, 0.10 to B, 0.10 to C]<br>
=C2=A0 0.42 [pays 0.21 to A, 0.10 to B, 0.10 to C]<br>
<br>
then, either:<br>
<br>
=C2=A0 a) if they&#39;re both committed with GROUP and sig_group_count =3D =
3, then<br>
=C2=A0 =C2=A0 =C2=A0the outputs must be [0.21 A, 0.10 B, 0.10 C, 0.21 A, 0.=
10 B, 0.10<br>
=C2=A0 =C2=A0 =C2=A0C], and you don&#39;t lose funds<br>
<br>
=C2=A0 b) if they&#39;re both committed with GROUP and the first is<br>
=C2=A0 =C2=A0 =C2=A0sig_group_count=3D3 and the second is sig_group_count=
=3D0, then the<br>
=C2=A0 =C2=A0 =C2=A0outputs can be [0.21 A, 0.10 B, 0.10 C, *anything] -- b=
ut in that<br>
=C2=A0 =C2=A0 =C2=A0case the second input is already signalling that it&#39=
;s meant to be<br>
=C2=A0 =C2=A0 =C2=A0paired with another input to fund the same three output=
s, so any<br>
=C2=A0 =C2=A0 =C2=A0funds loss is at least intentional<br>
<br>
Note that this means txids are very unstable: if a tx is only protected<br>
by SIGHASH_GROUP commitments then miners/relayers can add outputs, or<br>
reorganise the groups without making the tx invalid. Beyond requiring<br>
the signatures to be APO/APOAS-based to deal with that, we&#39;d also need<=
br>
to avoid txs getting rbf-pinned by some malicious third party who pulls<br>
apart the groups and assembles a new tx that&#39;s hard to rbf but also<br>
unlikely to confirm due to having a low feerate.<br>
<br>
Note also that not reusing addresses solves this case -- it&#39;s only a<br=
>
problem when you&#39;re paying the same amounts to the same addresses.<br>
<br>
Being able to combine additional inputs and outputs at a later date<br>
(which necessarily changes the txid) is an advantage though: it lets<br>
you add additional funds and claim change, which allows you to adjust<br>
to different fee rates.<br>
<br>
I don&#39;t think the SIGHASH_GROUP approach would work very well without<b=
r>
access to the annex, ie if you&#39;re trying to do CTV encoded either in a<=
br>
plain scriptPubKey or via segwit/p2sh.<br>
<br>
I think that would give 16 different sighashes, choosing one of four<br>
options for outputs,<br>
<br>
=C2=A0ALL/NONE/SINGLE/GROUP<br>
=C2=A0 =C2=A0-- which outputs are committed to<br>
<br>
and one of four options for inputs,<br>
<br>
=C2=A0-/ANYONECANPAY/ANYPREVOUT/ANYPREVOUTANYSCRIPT<br>
=C2=A0 =C2=A0-- all inputs committed to, specific input committed to,<br>
=C2=A0 =C2=A0 =C2=A0 scriptpubkey/tapscript committed to, or just the<br>
=C2=A0 =C2=A0 =C2=A0 nseq/annex/codesep_pos<br>
<br>
vs the ~155,000 sighashes in the TXHASH proposal.<br>
<br>
I don&#39;t think there&#39;s an efficient way of doing SIGHASH_GROUP via t=
x<br>
introspection opcodes that doesn&#39;t also introduce a quadratic hashing<b=
r>
risk -- you need to prevent different inputs from re-hashing distinct but<b=
r>
overlapping sets of outputs, and if your opcodes only allow grabbing one<br=
>
output at a time to add to the message being signed you have to do a lot<br=
>
of coding if you want to let the signer choose how many outputs to commit<b=
r>
to; if you provide an opcode that grabs man outputs to hash, it seems<br>
hard to do that generically in a way that avoids quadratic behaviour.<br>
<br>
So I think that suggests two alternative approaches, beyond the<br>
VERIFY-vs-PUSH semantic:<br>
<br>
=C2=A0- have a dedicated sighash type for CTV (either an explicit one for i=
t,<br>
=C2=A0 =C2=A0per bip119, or support thousands of options like the proposal =
in this<br>
=C2=A0 =C2=A0thread, one of which happens to be about the same as the bip11=
9 idea)<br>
<br>
=C2=A0- use ANYPREVOUTANYSCRIPT|GROUP for CTV, which means also implementin=
g<br>
=C2=A0 =C2=A0annex parsing and better RBF behaviour to avoid those txs bein=
g<br>
=C2=A0 =C2=A0excessively vulnerable to pinning; with the advantage being th=
at<br>
=C2=A0 =C2=A0txs using &quot;GROUP&quot; sigs can be combined either for ba=
tching purposes<br>
=C2=A0 =C2=A0or for adapting to the fee market after the signature has been=
 made,<br>
=C2=A0 =C2=A0and the disadvantage that you can&#39;t rely on stable txids w=
hen looking<br>
=C2=A0 =C2=A0for CTV spends and have to continue using APO/APOAS when chain=
ing<br>
=C2=A0 =C2=A0signatures on top of unconfirmed CTV outputs<br>
<br>
Cheers,<br>
aj<br>
<br>
[0] Here&#39;s bitmatrix trying to multiply two numbers together:<br>
=C2=A0 =C2=A0 =C2=A0<a href=3D"https://medium.com/bit-matrix/technical-how-=
does-bitmatrix-v1-multiply-two-integers-in-the-absence-of-op-mul-a58b7a3794=
a3" rel=3D"noreferrer" target=3D"_blank">https://medium.com/bit-matrix/tech=
nical-how-does-bitmatrix-v1-multiply-two-integers-in-the-absence-of-op-mul-=
a58b7a3794a3</a><br>
<br>
=C2=A0 =C2=A0 Likewise, doing a point preimage reveal via clever scripting<=
br>
=C2=A0 =C2=A0 pre-taproot never saw an implementation, despite seeming<br>
=C2=A0 =C2=A0 theoretically plausible.<br>
=C2=A0 =C2=A0 =C2=A0<a href=3D"https://lists.linuxfoundation.org/pipermail/=
lightning-dev/2015-November/000344.html" rel=3D"noreferrer" target=3D"_blan=
k">https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-November/=
000344.html</a><br>
<br>
[1] <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021=
-July/019243.html" rel=3D"noreferrer" target=3D"_blank">https://lists.linux=
foundation.org/pipermail/bitcoin-dev/2021-July/019243.html</a><br>
<br>
</blockquote></div></div>

--000000000000a8d80a05d7784da1--