Return-Path: Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id D25E6C0171 for ; 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 ; 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 ; 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 ; 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 ; Sun, 26 Jan 2020 12:24:09 -0500 Received: by mail-il1-f174.google.com with SMTP id o13so4979466ilg.10 for ; 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: In-Reply-To: From: Jeremy Date: Sun, 26 Jan 2020 09:23:57 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Billy , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: OP_SWAP OP_CAT OP_SWAP OP_CAT 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 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
Hi Billy,

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.

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

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.

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:

<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 fu= nction.

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

Best,

Jeremy
<= div>


On Sun, Jan 26, 2020 at 8:59 = AM Billy via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
I hav= e 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 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=A0bitcointalk.org= :

https://bitcointalk.org/index.php?topic=3D52= 20520=C2=A0=C2=A0
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--00000000000028ee00059d0e4277--