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 CF3961B38 for ; Tue, 28 May 2019 03:42:03 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40136.protonmail.ch (mail-40136.protonmail.ch [185.70.40.136]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E37F2A9 for ; Tue, 28 May 2019 03:42:02 +0000 (UTC) Date: Tue, 28 May 2019 03:41:58 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1559014920; bh=SfDZ20Hzq19ZeZiVu/bTG5lGw3Ww5hIROqF69H3zR/0=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=PDGwuVDwbADOUvYWzw0J8JF+05Zf4gVDdOE7laAwo7/RH1YCDTRm0bcJM5swCUza3 N5nL95IHk02atT7KGJX9cxaxF4+2uBS+sjBdXV1oTYVTTPFUWTv9owpPFX1hvrBsJk fVeD6cdwP/pPJ0EOsHnWiOx/us3zc5CENFMgu8sY= To: Anthony Towns , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: <20190527072128.lbzeo6h23qgxvhsy@erisian.com.au> References: <20190527072128.lbzeo6h23qgxvhsy@erisian.com.au> Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL, RCVD_IN_DNSWL_LOW 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: Thu, 30 May 2019 16:35:33 +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: Tue, 28 May 2019 03:42:04 -0000 Sent with ProtonMail Secure Email. =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Monday, May 27, 2019 3:21 PM, Anthony Towns via bitcoin-dev wrote: > On Wed, May 22, 2019 at 05:01:21PM -0400, Russell O'Connor via bitcoin-de= v wrote: > > > Bitcoin Script appears designed to be a flexible programmable system th= at > > provides generic features to be composed to achieve various purposes. > > Counterpoint: haven't the flexibly designed parts of script mostly been > a failure -- requiring opcodes to be disabled due to DoS vectors or > consensus bugs, and mostly not being useful in practice where they're > still enabled in BTC or on other chains where they have been re-enabled > (eg, Liquid and BCH)? One could argue that manually programming directly with `OP_CHECKSIGFROMSTA= CK` is difficult enough that we should really be using some compiler that (= say) translates Simplicity to SCRIPT that uses `OP_CHECKSIGFROMSTACK` to im= plement transaction introspection. So the lack of such use may point more to a lack of tools than a lack of ac= tual use. This extends in particular to "lack of abstraction"; the abstraction might = be better served by implementing a pure functional language that is compile= d down to `OP_CHECKSIGFROMSTACK` somehow, with the pure functional language= implementing loops using the technique I described (keep current state in = a separate `OP_RETURN` output, reuse the same `scriptPubKey` but modify the= `OP_RETURN` output (i.e. code is `const`, data is `mutable`)). But that still requires that we have at least a proof-of-existence in the f= orm of some compiler that targets (say) Liquid/Elements SCRIPT and leverage= s `OP_CHECKSIGFROMSTACK` appropriately. I believe Russell has expressed some interest in my Smart Contracts Unchain= ed technique to implement Simplicity on top of Bitcoin by using a semi-trus= ted user-selected federation to enforce Simplicity execution. If implemented as such, it may be possible to then show that actual use wou= ld be enabled if it is possible to run this on Bitcoin. (I respect that Blockstream employees have to eat and thus made Liquid, but= for example I myself would not be interested in putting any coins in Liqui= d, as its federation is not selected by me; I would be more willing to use = a Simplicity or `OP_CHECKSIGFROMSTACK` implementation on top of Smart Contr= acts Unchained as at least I can select the federation to include my own ha= rdware, and allow anyone I might want to form such contracts with to also s= elect federation members to include my own hardware.) (Of course Liquid is built on Elements and Elements is open-source and in t= heory I could just replace its federation with my own, but having to start = a new blockchain for every federation-set seems wasteful compared to Smart = Contracts Unchained; Elements does have the advantage of already actually e= xisting whereas no Smart Contracts Unchained exists at all.) Regards, ZmnSCPxj