From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id C6D221986 for ; Sun, 23 Jun 2019 06:43:37 +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 smtp1.linuxfoundation.org (Postfix) with ESMTPS id 091A8710 for ; Sun, 23 Jun 2019 06:43:36 +0000 (UTC) Received: from mail-ed1-f51.google.com (mail-ed1-f51.google.com [209.85.208.51]) (authenticated bits=0) (User authenticated as jlrubin@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x5N6hYuZ025774 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Sun, 23 Jun 2019 02:43:35 -0400 Received: by mail-ed1-f51.google.com with SMTP id z25so16390116edq.9 for ; Sat, 22 Jun 2019 23:43:35 -0700 (PDT) X-Gm-Message-State: APjAAAXDfRsp20rOcT4G518h9yMpVtLIHJn5m0Gusp2NOOMqnRhYL9TT 41unDDmoPTrGpMBTJBvfX9NnNZ3J1DaOzCUTcsI= X-Google-Smtp-Source: APXvYqx4WZYaBOZFCv6pz/C/ZR7IBcG3enMpdvjNuFcUCHSzvGoRuaBbGypbGuDN6COivZrJcNotrEwZo9qhcwdDZjc= X-Received: by 2002:aa7:cfc3:: with SMTP id r3mr24135619edy.202.1561272213949; Sat, 22 Jun 2019 23:43:33 -0700 (PDT) MIME-Version: 1.0 References: <20190605093039.xfo7lcylqkhsfncv@erisian.com.au> <20190620220552.metrqaul3iporwma@erisian.com.au> In-Reply-To: <20190620220552.metrqaul3iporwma@erisian.com.au> From: Jeremy Date: Sat, 22 Jun 2019 23:43:22 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Anthony Towns , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000b5d27a058bf80305" X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED 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: Sun, 23 Jun 2019 16:34:08 +0000 Subject: Re: [bitcoin-dev] OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY) X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2019 06:43:37 -0000 --000000000000b5d27a058bf80305 Content-Type: text/plain; charset="UTF-8" This is insufficient: sequences must be committed to because they affect TXID. As with scriptsigs (witness data fine to ignore). NUM_IN too. Any malleability makes this much less useful. -- @JeremyRubin On Fri, Jun 21, 2019 at 10:31 AM Anthony Towns via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Tue, Jun 18, 2019 at 04:57:34PM -0400, Russell O'Connor wrote: > > So with regards to OP_SECURETHEBAG, I am also "not really seeing any > reason to > > complicate the spec to ensure the digest is precommitted as part of the > > opcode." > > Also, I think you can simulate OP_SECURETHEBAG with an ANYPREVOUT > (NOINPUT) sighash (Johnson Lau's mentioned this before, but not sure if > it's been spelled out anywhere); ie instead of constructing > > X = Hash_BagHash( version, locktime, [outputs], [sequences], num_in ) > > and having the script be " OP_SECURETHEBAG" you calculate an > ANYPREVOUT sighash for SIGHASH_ANYPREVOUTANYSCRIPT | SIGHASH_ALL: > > Y = Hash_TapSighash( 0, 0xc1, version, locktime, [outputs], 0, > amount, sequence) > > and calculate a signature sig = Schnorr(P,m) for some pubkey P, and > make your script be "

CHECKSIG". > > That loses the ability to commit to the number of inputs or restrict > the nsequence of other inputs, and requires a bigger script (sig and P > are ~96 bytes instead of X's 32 bytes), but is otherwise pretty much the > same as far as I can tell. Both scripts are automatically satisfied when > revealed (with the correct set of outputs), and don't need any additional > witness data. > > If you wanted to construct "X" via script instead of hardcoding a value > because it got you generalised covenants or whatever; I think you could > get the same effect with CAT,LEFT, and RIGHT: you'd construct Y in much > the same way you construct X, but you'd then need to turn that into a > signature. You could do so by using pubkey P=G and nonce R=G, which > means you need to calculate s=1+hash(G,G,Y)*1 -- calculating the hash > part is easy, multiplying it by 1 is easy, and to add 1 you can probably > do something along the lines of: > > OP_DUP 4 OP_RIGHT 1 OP_ADD OP_SWAP 28 OP_LEFT OP_SWAP OP_CAT > > (ie, take the last 4 bytes, increment it using 4-byte arithmetic, > then cat the first 28 bytes and the result. There's overflow issues, > but I think they can be worked around either by allowing you to choose > different locktimes, or by more complicated script) > > Cheers, > aj > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --000000000000b5d27a058bf80305 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

This is insufficient: seq= uences must be committed to because they affect TXID. As with scriptsigs (w= itness data fine to ignore). NUM_IN too.

Any malleability makes this = much less useful.

<= /div>
O= n Fri, Jun 21, 2019 at 10:31 AM Anthony Towns via bitcoin-dev <bitcoin-dev@lists.linuxfo= undation.org> wrote:
On Tue, Jun 18, 2019 at 04:57:34PM -0400, Russell O'Connor = wrote:
> So with regards to OP_SECURETHEBAG, I am also "not really seeing = any reason to
> complicate the spec to ensure the digest is precommitted as part of th= e
> opcode."

Also, I think you can simulate OP_SECURETHEBAG with an ANYPREVOUT
(NOINPUT) sighash (Johnson Lau's mentioned this before, but not sure if=
it's been spelled out anywhere); ie instead of constructing

=C2=A0 X =3D Hash_BagHash( version, locktime, [outputs], [sequences], num_i= n )

and having the script be "<X> OP_SECURETHEBAG" you calculat= e an
ANYPREVOUT sighash for SIGHASH_ANYPREVOUTANYSCRIPT | SIGHASH_ALL:

=C2=A0 Y =3D Hash_TapSighash( 0, 0xc1, version, locktime, [outputs], 0,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0amount, sequence)

and calculate a signature sig =3D Schnorr(P,m) for some pubkey P, and
make your script be "<sig> <P> CHECKSIG".

That loses the ability to commit to the number of inputs or restrict
the nsequence of other inputs, and requires a bigger script (sig and P
are ~96 bytes instead of X's 32 bytes), but is otherwise pretty much th= e
same as far as I can tell. Both scripts are automatically satisfied when revealed (with the correct set of outputs), and don't need any addition= al
witness data.

If you wanted to construct "X" via script instead of hardcoding a= value
because it got you generalised covenants or whatever; I think you could
get the same effect with CAT,LEFT, and RIGHT: you'd construct Y in much=
the same way you construct X, but you'd then need to turn that into a signature. You could do so by using pubkey P=3DG and nonce R=3DG, which
means you need to calculate s=3D1+hash(G,G,Y)*1 -- calculating the hash
part is easy, multiplying it by 1 is easy, and to add 1 you can probably do something along the lines of:

=C2=A0 =C2=A0 OP_DUP 4 OP_RIGHT 1 OP_ADD OP_SWAP 28 OP_LEFT OP_SWAP OP_CAT<= br>
(ie, take the last 4 bytes, increment it using 4-byte arithmetic,
then cat the first 28 bytes and the result. There's overflow issues, but I think they can be worked around either by allowing you to choose
different locktimes, or by more complicated script)

Cheers,
aj

_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000b5d27a058bf80305--