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 733E9109B for ; Fri, 24 May 2019 20:51:36 +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 DA1FBF4 for ; Fri, 24 May 2019 20:51:35 +0000 (UTC) Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com [209.85.208.43]) (authenticated bits=0) (User authenticated as jlrubin@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x4OKpXrv015411 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Fri, 24 May 2019 16:51:34 -0400 Received: by mail-ed1-f43.google.com with SMTP id w33so12656627edb.10 for ; Fri, 24 May 2019 13:51:34 -0700 (PDT) X-Gm-Message-State: APjAAAVBOGMXAH3+J5LvhuY6DYZtXy2QNnGGUtOpGOK1l/kUF1eCXpfy Hn0DRdOrvcj1MYEmvDDuLRSltXvU7FD7RiAVtzg= X-Google-Smtp-Source: APXvYqzlfzG/l4fuHbHq7QGP17t4TtSGNb+Z5fJF3OLB7Qp5QbU0gClX8OoI06ExeHzZLXSNk5q0TaSeflur+lyB1rc= X-Received: by 2002:a50:84e7:: with SMTP id 94mr105817644edq.137.1558731092954; Fri, 24 May 2019 13:51:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jeremy Date: Fri, 24 May 2019 13:51:21 -0700 X-Gmail-Original-Message-ID: Message-ID: To: "Russell O'Connor" , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000001893750589a85dd7" 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: Sat, 25 May 2019 12:07:05 +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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2019 20:51:36 -0000 --0000000000001893750589a85dd7 Content-Type: text/plain; charset="UTF-8" Hi Russell, Thanks for this detailed comparison. The COSHV BIP does include a brief comparison to OP_CHECKSIGFROMSTACKVERIFY and ANYPREVOUT, but this is more detailed. I think that the power from CHECKSIGFROMSTACKVERIFY is awesome. It's clearly one of the more flexible options available and would enable a multitude of new use cases. When I originally presented my work on congestion control at Jan 2017 BPASE, I also discussed it as an option for covenants. Unfortunately I think it may be on the edge of too powerful -- there are a lot of use cases and implications from having a potentially recursive covenant. If you see my response to Matt in the OP_COSHV BIP thread I classify it as enabling a non-computationally enumerable set of restrictions. I think also from a developer point of view working with OP_COSHV is much much simpler (maybe this can be abstracted) which will lead to increased adoption. OP_COSHV also uses less per-block bandwidth which also makes it preferable for a measure intended to decongest blocks. Do you know the exact byte cost for OP_CHECKSIGFROMSTACK? OP_COSHV scripts, with templating changes to taproot, can be a single byte. OP_COSHV also has less potential to have a negative interaction with future opcodes we may want like OP_PUBKEYTWEAK. While we're getting to an exact spec for the features we want in Bitcoin scripting, it's hard to sign on to OP_CHECKSIGFROMSTACK unless there's an exact specification which makes us confident we're hitting all the points. If the main complaint about OP_COSHV is that it peeks at surrounding data, it's also possible to implement it more closely to a multi-byte pushdata opcode or do the template optimization. Lastly, as I have previously noted, OP_LEFT is probably safer to implement than OP_CAT and should be more efficient for OP_CHECKSIGFROMSTACK scripts. --0000000000001893750589a85dd7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Russell,

Thanks for this detailed comparison. The COSHV BIP does include a brief c= omparison to OP_CHECKSIGFROMSTACKVERIFY and ANYPREVOUT, but this is more de= tailed.


I think t= hat the power from CHECKSIGFROMSTACKVERIFY is awesome. It's clearly one= of the more flexible options available and would enable a multitude of new= use cases.

When I originally presented my work on congestion= control at Jan 2017 BPASE, I also discussed it as an option for covenants.= Unfortunately I think it may be on the edge of too powerful -- there are a= lot of use cases and implications from having a potentially recursive cove= nant. If you see my response to Matt in the OP_COSHV BIP thread I classify = it as enabling a non-computationally enumerable set of restrictions.

I think also from a developer point of view working with OP_COSH= V is much much simpler (maybe this can be abstracted) which will lead to in= creased adoption. OP_COSHV also uses less per-block bandwidth which also ma= kes it preferable for a measure intended to decongest blocks. Do you know t= he exact byte cost for OP_CHECKSIGFROMSTACK? OP_COSHV scripts, with templat= ing changes to taproot, can be a single byte. OP_COSHV also has less potent= ial to have a negative interaction with future opcodes we may want like OP_= PUBKEYTWEAK. While we're getting to an exact spec for the features we w= ant in Bitcoin scripting, it's hard to sign on to OP_CHECKSIGFROMSTACK = unless there's an exact specification which makes us confident we'r= e hitting all the points.

=
If the main complaint about OP_CO= SHV is that it peeks at surrounding data, it's also possible to impleme= nt it more closely to a multi-byte pushdata opcode or do the template optim= ization.

Lastly, as I have previously noted, OP_LEFT is probabl= y safer to implement than OP_CAT and should be more efficient for OP_CHECKS= IGFROMSTACK scripts.

--0000000000001893750589a85dd7--