path: root/d0/f92df9895b3b7c1ac6bd8d2c8dfc82a4911ed0

Return-Path: <jaejoon@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id AFDE6F0A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 23 May 2019 17:36:36 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vs1-f52.google.com (mail-vs1-f52.google.com
	[209.85.217.52])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BE91287D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 23 May 2019 17:36:35 +0000 (UTC)
Received: by mail-vs1-f52.google.com with SMTP id c24so4089239vsp.7
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 23 May 2019 10:36:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:references:in-reply-to:from:date:message-id:subject:to; 
	bh=KmeA6I4FoQeOE/zbt5K4ykl0pP3UtekncJ7OuKUix2Q=;
	b=bsk3o5rFk5xy5TP+Amruhl77cg8OgTxSsrtj66vdO0yCCai8GOse9/smTo59qa1Y8r
	zGT+yAtPDC4kMNo47yweTxH/bd8lvbQxfiP0XZiVPgsjem6wistY2whtqRQIZpNFP73F
	JCmS69OZvPWRDcMMJWHeoWs2P7tJKJXlEY1UTAS3WQ+xzca8RWbg5HNZJ7PH+9tPhWDb
	tBTMujRqkLbHsMPEkpRgYFYekKZBK/g7LIagQuu2LjRGrJ4y9tXaxLI/k7Hlm7KbCRQR
	wLy4nFNahETNF3svcXquTTMlsir+nEU8NglqjbSZe6nHMQtbgYUlA/yonxjAxie4Dc9q
	csGw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:references:in-reply-to:from:date
	:message-id:subject:to;
	bh=KmeA6I4FoQeOE/zbt5K4ykl0pP3UtekncJ7OuKUix2Q=;
	b=GTTASsBMT9b9E5l5mo5bQww+Cgr7jKhT/sREBMsohwWp/tC0sF3jLxTf4HWZ33AXDA
	NRPtEOXZaLp+TTvdQEEIzqG0foonrC3OO0Aa/aP5PWZ+hxvwuUCbuW584YLQziOlLJo1
	ZvzcRU0/XWJSdkQYTbFeavnNtMOxGgMEsi2EtLgsJuafg4MkC94TeTVA0hC5afTYid1W
	kv7bsJbvmTmKY85fPZ/L5G2jCAVYt9f2LXZjsHvHmviOe1fpLBhyXHvbDnSmasQ+rBc8
	8Ce+t+zIfw76S+L46rvUtmQAx4G8BxYt6Ok/4pTg8Y7hLOjBnZ1HS5v/hxINXt+RqDp4
	79vA==
X-Gm-Message-State: APjAAAVYkktJFAsmQqVPm6FN/EpkOIu3ZWs0pWD/WEWPLF5o8oRzZosR
	Ne/Tt7TncVMG858qm1EUl9KfX7lfbpo9uWBDGgI=
X-Google-Smtp-Source: APXvYqwe6BzrdhxFsvYheKP943LbG3nalNgV/C3KolBzObgDtWUFmU6s/sTMsNJCDXNbRsSLM/FM6p/jnRsQ/HJP6gw=
X-Received: by 2002:a67:ed55:: with SMTP id m21mr47062500vsp.201.1558632994711;
	Thu, 23 May 2019 10:36:34 -0700 (PDT)
MIME-Version: 1.0
References: <CAMZUoK=0YhqxguphmaKsMGZCy_NYVE_i53qGBfPVES=GAYTy1g@mail.gmail.com>
In-Reply-To: <CAMZUoK=0YhqxguphmaKsMGZCy_NYVE_i53qGBfPVES=GAYTy1g@mail.gmail.com>
From: Jimmy Song <jaejoon@gmail.com>
Date: Thu, 23 May 2019 12:36:19 -0500
Message-ID: <CAJR7vkqogCzy8_SpCxcAhnEdkS6DRKaDtvJa8Wc-TNGsCcjM5g@mail.gmail.com>
To: "Russell O'Connor" <roconnor@blockstream.io>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000fc2edc0589918517"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 23 May 2019 18:31:16 +0000
Subject: Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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: Thu, 23 May 2019 17:36:36 -0000

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

Hi Russell,

This is probably a dumb question, but I'd like to get some clarity on your
proposal.

OP_CHECKSIGFROMSTACKVERIFY would pop off a signature, message and pubkey.
Presumably, the message would then have to get constructed as part of the
Script execution. What would such a message look like? What, in other
words, would you be signing and would that be similar to what signatures
sign now? Would it be a single blob that incorporates all the input/output
information in some hashed manner (like BIP143)? Or would you need separate
signatures for different parts of the transaction? Or is it something more
complicated like aggregating multiple signatures over different parts of
the transaction?

Best,

Jimmy

On Thu, May 23, 2019 at 8:35 AM Russell O'Connor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Recently there have been some tapscript proposals, SIGHASH_ANYPREVOUT and
> OP_CHECKOUTPUTHASHVERIFY, that aim to enable particular new features for
> Bitcoin via new Script operations.  However, I think that these proposals
> miss the mark when it comes to how they approach Bitcoin Script and
> language features.
>
> Bitcoin Script appears designed to be a flexible programmable system that
> provides generic features to be composed to achieve various purposes.
> Thus, when we design new language features for Script, we should be
> striving, as much as possible, to similarly build general purpose tools
> which can in turn be used for a variety of purposes.
>
> I feel the SIGHASH_ANYPREVOUT and OP_CHECKOUTPUTHASHVERIFY proposals fail
> to achieve these design goals.  They are both are designed with very narrow
> applications in mind, while also going out of their way to extend the
> semantic domain of the interpretation of Bitcoin operations in new ways
> that complicate their specification.  In the case of SIGHASH_ANYPREVOUT,
> the semantic domain is extended by adding new counters to track the use of
> various v0 and v2 signature types.  In the case of
> OP_CHECKOUTPUTHASHVERIFY, it employs a new context-sensitive operation that
> peeks at the value of surrounding opcodes.
>
> Instead, I propose that, for the time being, we simply implement OP_CAT
> and OP_CHECKSIGFROMSTACKVERIFY.  OP_CAT pops two byte arrays off the stack
> and pushes their concatenation back onto the stack.
> OP_CHECKSIGFROMSTACKVERIFY pops a signature, message, and pubkey off the
> stack and performs a bip-schnorr verification on the SHA256 hash of the
> message.
>
> In concert, these two operations enable:
>
> * Oracle signature verification, including discrete log contracts.
> * Amortized secure multiparty computations (see "Amortizing Secure
> Computation with Penalties" by Kumaresan and Bentov).
> * Transaction introspection including:
> + Simulated SIGHASH_ANYPREVOUT, which are necessarily chaperoned simply
> by the nature of the construction.
> + Decide if a transaction has exactly one input or not. (etc.)
> + Weak covenants, which can verify output scripts to see if they are among
> a set of predefined values or verify the output hash.
>
> and presumably more applications as well.
>
> For better or for worse, without an OP_PUBKEYTWEEK operation available,
> the more interesting recursive-covenants remain largely out of reach, with
> the exception of a recursive covenant that is only able to send back to its
> own address, possibly abusing its own TXO value as a state variable.
>
> All this is accomplished by two straightforward opcodes whose semantics
> are pure computational operations on stack values.  The only semantic
> side-effect is that OP_CHECKSIGFROMSTACKVERIFY would count towards the
> existing 'sigops_passed' count.  Moreover, I feel that adding these
> operations does not preclude adding more specialized opcodes in the future
> as an optimization for whatever popular constructions come up, once we know
> what those are.
>
> I feel that this style of generic building blocks truly embodies what is
> meant by "programmable money".
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">Hi Russell,<div><br></div><div>This is probably a dumb que=
stion, but I&#39;d like to get some clarity on your proposal.</div><div><br=
></div><div>OP_CHECKSIGFROMSTACKVERIFY would pop off a signature, message a=
nd pubkey. Presumably, the message would then have to get constructed as pa=
rt of the Script execution. What would such a message look like? What, in o=
ther words, would you be signing and would that be similar to what signatur=
es sign now? Would it be a single blob that incorporates all the input/outp=
ut information in some hashed manner (like BIP143)? Or would you need separ=
ate signatures for different parts of the transaction? Or is it something m=
ore complicated like aggregating multiple signatures over different parts o=
f the transaction?</div><div><br></div><div>Best,</div><div><br></div><div>=
Jimmy</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"g=
mail_attr">On Thu, May 23, 2019 at 8:35 AM Russell O&#39;Connor via bitcoin=
-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d=
ev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"l=
tr"><div dir=3D"ltr"><div dir=3D"ltr"><div>Recently there have been some ta=
pscript proposals, SIGHASH_ANYPREVOUT and OP_CHECKOUTPUTHASHVERIFY, that ai=
m to enable particular new features for Bitcoin via new Script operations.=
=C2=A0 However, I think that these proposals miss the mark when it comes to=
 how they approach Bitcoin Script and language features.</div><div><br></di=
v><div>Bitcoin Script appears designed to be a flexible programmable system=
 that provides generic features to be composed to achieve various purposes.=
=C2=A0 Thus, when we design new language features for Script, we should be =
striving, as much as possible,  to similarly build general purpose tools wh=
ich can in turn be used for a variety of purposes.</div><div><br></div><div=
>I feel the SIGHASH_ANYPREVOUT and OP_CHECKOUTPUTHASHVERIFY proposals fail =
to achieve these design goals.=C2=A0 They are both are designed with very n=
arrow applications in mind, while also going out of their way to extend the=
 semantic domain of the interpretation of Bitcoin operations in new ways th=
at complicate their specification.=C2=A0 In the case of SIGHASH_ANYPREVOUT,=
 the semantic domain is extended by adding new counters to track the use of=
 various v0 and v2 signature types.=C2=A0 In the case of OP_CHECKOUTPUTHASH=
VERIFY, it employs a new context-sensitive operation that peeks at the valu=
e of surrounding opcodes.</div><div><br></div><div>Instead, I propose that,=
 for the time being, we simply implement OP_CAT and OP_CHECKSIGFROMSTACKVER=
IFY.=C2=A0 OP_CAT pops two byte arrays off the stack and pushes their conca=
tenation back onto the stack.=C2=A0 OP_CHECKSIGFROMSTACKVERIFY pops a signa=
ture, message, and pubkey off the stack and performs a bip-schnorr verifica=
tion on the SHA256 hash of the message.<br></div><div><br></div><div>In con=
cert, these two operations enable:</div><div><br></div><div>* Oracle signat=
ure verification, including discrete log contracts.</div><div>* Amortized s=
ecure multiparty computations (see &quot;Amortizing Secure Computation with=
 Penalties&quot; by Kumaresan and Bentov).</div><div>* Transaction introspe=
ction including:<br></div><div><a class=3D"gmail_plusreply" id=3D"gmail-m_-=
496123689612879534gmail-plusReplyChip-0">+</a>=C2=A0Simulated SIGHASH_ANYPR=
EVOUT, which are necessarily chaperoned simply by the nature of the constru=
ction.<br></div><div><a class=3D"gmail_plusreply" id=3D"gmail-m_-4961236896=
12879534gmail-plusReplyChip-1">+</a> Decide if a transaction has exactly on=
e input or not. (etc.)</div><div>+ Weak covenants, which can verify output =
scripts to see if they are among a set of predefined values or verify the o=
utput hash.<br></div><div><br></div><div>and presumably more applications a=
s well.<br></div><div><br></div><div>For better or for worse, without an OP=
_PUBKEYTWEEK operation available, the more interesting recursive-covenants =
remain largely out of reach, with the exception of a recursive covenant tha=
t is only able to send back to its own address, possibly abusing its own TX=
O value as a state variable.</div><div><br></div><div>All this is accomplis=
hed by two straightforward opcodes whose semantics are pure computational o=
perations on stack values.=C2=A0 The only semantic side-effect is that OP_C=
HECKSIGFROMSTACKVERIFY would count towards the existing &#39;sigops_passed&=
#39; count.=C2=A0 Moreover, I feel that adding these operations does not pr=
eclude adding more specialized opcodes in the future as an optimization for=
 whatever popular constructions come up, once we know what those are.<br></=
div><div><br></div><div>I feel that this style of generic building blocks t=
ruly embodies what is meant by &quot;programmable money&quot;.<br></div></d=
iv></div></div></div></div>
_______________________________________________<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>

--000000000000fc2edc0589918517--