Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK

[ZmnSCPxj <ZmnSCPxj@protonmail.com>]

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
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-dev wrote:
>
> > Bitcoin Script appears designed to be a flexible programmable system that
> > 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_CHECKSIGFROMSTACK` is difficult enough that we should really be using some compiler that (say) translates Simplicity to SCRIPT that uses `OP_CHECKSIGFROMSTACK` to implement transaction introspection.
So the lack of such use may point more to a lack of tools than a lack of actual use.

This extends in particular to "lack of abstraction"; the abstraction might be better served by implementing a pure functional language that is compiled 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 form of some compiler that targets (say) Liquid/Elements SCRIPT and leverages `OP_CHECKSIGFROMSTACK` appropriately.

I believe Russell has expressed some interest in my Smart Contracts Unchained technique to implement Simplicity on top of Bitcoin by using a semi-trusted user-selected federation to enforce Simplicity execution.
If implemented as such, it may be possible to then show that actual use would 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 Liquid, 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 Contracts Unchained as at least I can select the federation to include my own hardware, and allow anyone I might want to form such contracts with to also select federation members to include my own hardware.)
(Of course Liquid is built on Elements and Elements is open-source and in theory 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 existing whereas no Smart Contracts Unchained exists at all.)

Regards,
ZmnSCPxj