Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id C251BE51 for ; Fri, 24 May 2019 23:07:41 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-it1-f180.google.com (mail-it1-f180.google.com [209.85.166.180]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F14666C5 for ; Fri, 24 May 2019 23:07:40 +0000 (UTC) Received: by mail-it1-f180.google.com with SMTP id h20so18429687itk.4 for ; Fri, 24 May 2019 16:07:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blockstream.io; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TWpDAx7x56lZ4/SC0JdA2vm10xqInTUW334DjUwLfQc=; b=rHURuX2/G72CZfH1QoNIoE0yTPBOfb2alOZarPF9K8FvwBMHu263t3jeCWFXtARCuC WJruhIjR8PNH+KJNNNzfckUwucXUitOeEOQQ4KFLP1kkLopDfhHERLiAxgJ9V5fcK6/p aTxgnaW0N+tBOroS1qtT5ogO+7CaLbHWoc1Yc= 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:cc; bh=TWpDAx7x56lZ4/SC0JdA2vm10xqInTUW334DjUwLfQc=; b=PBOQvmNovz4FHGIBn9wpysz1Xx/bazyTqqFUrypE5L86MBjdJZkbhQHsr2auIwq9NZ QnsM24It9I1wioUGBkaPPWpeWkEQc0d58/myQktbWVLS+yKOngKemB4sjGnhTKL4xD72 L8zsY7zDWUVf3QRK1sJcS58C/sBpy01gWmFAOyGfibI2ebqU4OTqmD+JspUKQZjeQ1IS kZKFTkkmncZ1w39oRXaNEEDf0B9qikkhyZ8NA8y5rO2Y2lIIf+kpIgqTbrYCBNMAqb8n MJ9Qca1IKPSoUApDWiIBeEjGhcWdddxCL3nfRTTdZpjIXzGXnCp15mZrMnNJ+Sf+mYLf tllg== X-Gm-Message-State: APjAAAVZltpRIjB0MGA5mC17RoOwxf8B6AHDc7KUWEjv0qswbY7/H5we ibt4RCyjot563Y4/bkxVOdb1WXfdpDCakYm6ff61DQ== X-Google-Smtp-Source: APXvYqwLJhNCWEanXhsGYuCH/PxcQ8+MzoKJCFtvZGkB0TWXuHVFoiieH+5PqY+l144sQR7pYRCZxOtnX9y0Ho2yrwg= X-Received: by 2002:a05:660c:50:: with SMTP id p16mr19142420itk.146.1558739260222; Fri, 24 May 2019 16:07:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Russell O'Connor" Date: Fri, 24 May 2019 19:07:28 -0400 Message-ID: To: Jeremy Content-Type: multipart/alternative; boundary="000000000000e7417c0589aa43f2" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, 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: Sat, 25 May 2019 12:05:39 +0000 Cc: Bitcoin Protocol Discussion 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 23:07:41 -0000 --000000000000e7417c0589aa43f2 Content-Type: text/plain; charset="UTF-8" In order of escalating scope of amendments to OP_COSHV, I suggest 1) Peeking at surrounding data surrounding data should definitely be replaced by a pushdata-like op-code that uses the subsequent 32-bytes directly. The OP_SUCCESSx upgrade path specifically allows for this, and avoids complicating the semantics Bitcoin Script. 2) Furthermore, the number-of-input-verification and the outputhash-verification operations ought to be split into different opcodes as they are logically unrelated. 3) Better still, we should instead implement the transaction reflection operations of OP_PUSHOUTPUTHASH and OP_NUMINPUTS that puts the outputhash and number of inputs respectively onto the stack. Recursive covenants appear to be effectively impossible without either an OP_TWEEKPUBKEY or an OP_PUSHSCRIPTPUBKEY so the effort your proposal goes through to guard against placing an arbitrary outputhash onto the stack appears to be wasted effort to me. 4) If we anticipate adding OP_CHECKSIGFROMSTACKVERIFY, then we should most definitely prefer (3) instead of OP_COSHV, if we still feel the need to do anything at all. It is probably best to have both OP_CHECKSIGFROMSTACKVERIFY and transaction reflection operations of OP_PUSHOUTPUTHASH and OP_NUMINPUTS but I think I would be fine with just OP_CHECKSIGFROMSTACKVERIFY as well. On the other hand, if we are serious about preferring less per-block bandwidth over reusable primitive opcodes for programming, then we should instead abandon the RISC-style Bitcoin Script and instead add an alternative CISC-style taproot leaf type that directly provides (a conjunction of) the various popular common policies: channel opening, channel factories, coinjoins, hashlocks, timelocks, congestion control etc. Segwit v0 already implements this CISC-style for the single most popular policy: single signature verification. On Fri, May 24, 2019 at 4:51 PM Jeremy wrote: > 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. > > --000000000000e7417c0589aa43f2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In order of escalating scope of amendments to OP_COSH= V, I suggest

1) Peeking at surrounding data su= rrounding data should definitely be replaced by a pushdata-like op-code tha= t uses the subsequent 32-bytes directly.=C2=A0 The OP_SUCCESSx upgrade path= specifically allows for this, and avoids complicating the semantics Bitcoi= n Script.
2) Furthermore, the number-of-input-verification an= d the outputhash-verification operations ought to be split into different o= pcodes as they are logically unrelated.
3) Better still, we s= hould instead implement the transaction reflection operations of OP_PUSHOUT= PUTHASH and OP_NUMINPUTS that puts the outputhash and number of inputs resp= ectively onto the stack.=C2=A0 Recursive covenants appear to be effectively= impossible without either an OP_TWEEKPUBKEY or an OP_PUSHSCRIPTPUBKEY so t= he effort your proposal goes through to guard against placing an arbitrary = outputhash onto the stack appears to be wasted effort to me.
= 4) If we anticipate adding OP_CHECKSIGFROMSTACKVERIFY, then we should most = definitely prefer (3) instead of OP_COSHV, if we still feel the need to do = anything at all.=C2=A0 It is probably best to have both OP_CHECKSIGFROMSTAC= KVERIFY and transaction reflection operations of OP_PUSHOUTPUTHASH and OP_N= UMINPUTS but I think I would be fine with just OP_CHECKSIGFROMSTACKVERIFY a= s well.

On the other hand, if we are serious a= bout preferring less per-block bandwidth over reusable primitive opcodes fo= r programming, then we should instead abandon the RISC-style Bitcoin Script= and instead add an alternative CISC-style taproot leaf type that directly = provides (a conjunction of) the various popular common policies: channel op= ening, channel factories, coinjoins, hashlocks, timelocks, congestion contr= ol etc.=C2=A0 Segwit v0 already implements this CISC-style for the single m= ost popular policy: single signature verification.

=
On Fri, Ma= y 24, 2019 at 4:51 PM Jeremy <jlrubin@mit.edu> wrote:
Hi Russell,

Thanks for this detailed comparison. The CO= SHV BIP does include a brief comparison to OP_CHECKSIGFROMSTACKVERIFY and A= NYPREVOUT, but this is more detailed.


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

When I originally presented my work on congestion control at Jan 2= 017 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.
<= br>
I think also from a developer point of view working wi= th 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 whi= ch also makes it preferable for a measure intended to decongest blocks. Do = you know the exact byte cost for OP_CHECKSIGFROMSTACK? OP_COSHV scripts, wi= th templating changes to taproot, can be a single byte. OP_COSHV also has l= ess potential to have a negative interaction with future opcodes we may wan= t like OP_PUBKEYTWEAK. While we're getting to an exact spec for the fea= tures we want in Bitcoin scripting, it's hard to sign on to OP_CHECKSIG= FROMSTACK unless there's an exact specification which makes us confiden= t we're hitting all the points.

If the main complaint about OP_COSHV is that it peeks at surrounding da= ta, it's also possible to implement it more closely to a multi-byte pus= hdata 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.

--000000000000e7417c0589aa43f2--