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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
