path: root/a9/9ec5034f7533f0fcabdcc99128d0834265da86

Return-Path: <jlrubin@mit.edu>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id D25E6C0171
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 26 Jan 2020 17:24:11 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by fraxinus.osuosl.org (Postfix) with ESMTP id B7BF685BC8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 26 Jan 2020 17:24:11 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id thYpx-fKzQgL
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 26 Jan 2020 17:24:11 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
 by fraxinus.osuosl.org (Postfix) with ESMTPS id B632585B9A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 26 Jan 2020 17:24:10 +0000 (UTC)
Received: from mail-il1-f174.google.com (mail-il1-f174.google.com
 [209.85.166.174]) (authenticated bits=0)
 (User authenticated as jlrubin@ATHENA.MIT.EDU)
 by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00QHO81Y025883
 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
 for <bitcoin-dev@lists.linuxfoundation.org>; Sun, 26 Jan 2020 12:24:09 -0500
Received: by mail-il1-f174.google.com with SMTP id o13so4979466ilg.10
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 26 Jan 2020 09:24:09 -0800 (PST)
X-Gm-Message-State: APjAAAV5KFyuQGVl3FqqToQ8qm9uhXn1fS45xVXzZO46Qj5UIjXeic1C
 OSFjHpDG37ql+ljTeLeJ+qee7PvlOu3l1vLFHvU=
X-Google-Smtp-Source: APXvYqzS23wcNS625NDWUqeLtGPSe1bn4qE5weEpBni5b/PqasS9Sy1Rkm3y6BM5n/GCUIkNh2KLhhBbvW02fQWCuvA=
X-Received: by 2002:a92:3f0f:: with SMTP id m15mr11994947ila.164.1580059448632; 
 Sun, 26 Jan 2020 09:24:08 -0800 (PST)
MIME-Version: 1.0
References: <CAGpPWDYYYYEeuQVL6d97_OwN_f8ektdqv-5zXVT9fEqiS6qtoQ@mail.gmail.com>
In-Reply-To: <CAGpPWDYYYYEeuQVL6d97_OwN_f8ektdqv-5zXVT9fEqiS6qtoQ@mail.gmail.com>
From: Jeremy <jlrubin@mit.edu>
Date: Sun, 26 Jan 2020 09:23:57 -0800
X-Gmail-Original-Message-ID: <CAD5xwhg9848ptvGS-tct4Ofpcucef3Qi9XhDQEYzEpM+-ydZMw@mail.gmail.com>
Message-ID: <CAD5xwhg9848ptvGS-tct4Ofpcucef3Qi9XhDQEYzEpM+-ydZMw@mail.gmail.com>
To: Billy <fresheneesz@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000028ee00059d0e4277"
Subject: Re: [bitcoin-dev] op_checktemplateverify and number of inputs
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: Sun, 26 Jan 2020 17:24:12 -0000

--00000000000028ee00059d0e4277
Content-Type: text/plain; charset="UTF-8"

Hi Billy,

Restricting the number of inputs is necessary to preclude TXID
malleability. Committing to all of the information required necessitates
that the number of inputs be committed.

This allows us to build non-interactive layer 2 protocols which depend on
TXID non-malleability (most of them at writing).

You raise a good point that allowing *any number* of inputs is an
interesting case, which I had discussed offline with a few different
people. I think the conclusion was that that flexibility is better left
outside of the OP directly.

If you want an any number of inputs template, and we enable something like
OP_CAT (e.g., OP_CAT, OP_SHA256STREAM) then you can spend to something like:

<hash data before # inputs> OP_SWAP OP_CAT OP_SWAP OP_CAT <data post #
inputs> OP_CAT OP_SHA256 OP_CTV

And then pass in the # of inputs and sequences hash as arguments to the
function.

I can respond separately to your bitcointalk post as you ask a different
set of questions there.

Best,

Jeremy
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>


On Sun, Jan 26, 2020 at 8:59 AM Billy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I have a question about op_ctv related to the requirement to specify the
> number of inputs. I don't quite see why its necessary, but most
> importantly, I don't see why we want to *require* the user of the op to
> specify the number of inputs, tho I see the reasoning why one would want to
> specify it. If the op allowed both cases (specifying a number of inputs and
> allowing any number), it seems like the best of both worlds. I started a
> discussion on bitcointalk.org:
>
> https://bitcointalk.org/index.php?topic=5220520
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000">Hi Billy,</div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:#000000">Restricti=
ng the number of inputs is necessary to preclude TXID malleability. Committ=
ing to all of the information required necessitates that the number of inpu=
ts be committed.</div><div class=3D"gmail_default" style=3D"font-family:ari=
al,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:#000000">This allows us to build non-interactive layer 2 prot=
ocols which depend on TXID non-malleability (most of them at writing).</div=
><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-ser=
if;font-size:small;color:#000000"><br></div><div class=3D"gmail_default" st=
yle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000=
">You raise a good point that allowing *any number* of inputs is an interes=
ting case, which I had discussed offline with a few different people. I thi=
nk the conclusion was that that flexibility is better left outside of the O=
P directly.</div><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"g=
mail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:sma=
ll;color:#000000">If you want an any number of inputs template, and we enab=
le something like OP_CAT (e.g., OP_CAT, OP_SHA256STREAM) then you can spend=
 to something like:<br></div><div class=3D"gmail_default" style=3D"font-fam=
ily:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><di=
v class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;f=
ont-size:small;color:#000000">&lt;hash data before # inputs&gt; OP_SWAP OP_=
CAT OP_SWAP OP_CAT &lt;data post # inputs&gt; OP_CAT OP_SHA256 OP_CTV</div>=
<div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-seri=
f;font-size:small;color:#000000"><br></div><div class=3D"gmail_default" sty=
le=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"=
>And then pass in the # of inputs and sequences hash as arguments to the fu=
nction.</div><div class=3D"gmail_default" style=3D"font-family:arial,helvet=
ica,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail=
_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c=
olor:#000000">I can respond separately to your bitcointalk post as you ask =
a different set of questions there.<br></div><div class=3D"gmail_default" s=
tyle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#00000=
0"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helvet=
ica,sans-serif;font-size:small;color:#000000">Best,</div><div class=3D"gmai=
l_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;=
color:#000000"><br></div><div class=3D"gmail_default" style=3D"font-family:=
arial,helvetica,sans-serif;font-size:small;color:#000000">Jeremy<br></div><=
div><div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_sign=
ature"><div dir=3D"ltr">--<br><a href=3D"https://twitter.com/JeremyRubin" t=
arget=3D"_blank">@JeremyRubin</a><a href=3D"https://twitter.com/JeremyRubin=
" target=3D"_blank"></a></div></div></div><br></div><br><div class=3D"gmail=
_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Jan 26, 2020 at 8:59 =
AM Billy via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfound=
ation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>I hav=
e a question about op_ctv related to the requirement to specify the number =
of inputs. I don&#39;t quite see why its necessary, but most importantly, I=
 don&#39;t see why we want to *require* the user of the op to specify the n=
umber of inputs, tho I see the reasoning why one would want to specify it. =
If the op allowed both cases (specifying a number of inputs and allowing an=
y number), it seems like the best of both worlds. I started a discussion on=
=C2=A0<a href=3D"http://bitcointalk.org/" target=3D"_blank">bitcointalk.org=
</a>:</div><div><br></div><a href=3D"https://bitcointalk.org/index.php?topi=
c=3D5220520" target=3D"_blank">https://bitcointalk.org/index.php?topic=3D52=
20520</a>=C2=A0=C2=A0<br></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>

--00000000000028ee00059d0e4277--