Date: Tue, 28 May 2019 03:41:58 +0000
To: Anthony Towns <aj@erisian.com.au>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <oUAmCZn8d8qxim0QgUJDaseoYn_52GuYm-1G88WRHmCe60t_pcbx_NL_Opn6HbEKklGuteRLbtEPVRC_JaNm9qJ_Opbbw3DkC0mLzTbXmWs=@protonmail.com>
In-Reply-To: <20190527072128.lbzeo6h23qgxvhsy@erisian.com.au>
References: <CAMZUoK=0YhqxguphmaKsMGZCy_NYVE_i53qGBfPVES=GAYTy1g@mail.gmail.com>
	<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
Subject: Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK
Precedence: list


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 <bitcoin-dev=
@lists.linuxfoundation.org> 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