From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Anthony Towns <aj@erisian•com.au>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK
Date: Tue, 28 May 2019 03:41:58 +0000 [thread overview]
Message-ID: <oUAmCZn8d8qxim0QgUJDaseoYn_52GuYm-1G88WRHmCe60t_pcbx_NL_Opn6HbEKklGuteRLbtEPVRC_JaNm9qJ_Opbbw3DkC0mLzTbXmWs=@protonmail.com> (raw)
In-Reply-To: <20190527072128.lbzeo6h23qgxvhsy@erisian.com.au>
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
next prev parent reply other threads:[~2019-05-28 3:42 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-22 21:01 Russell O'Connor
2019-05-23 16:59 ` ZmnSCPxj
2019-05-23 22:06 ` Russell O'Connor
2019-05-23 17:36 ` Jimmy Song
2019-05-23 22:00 ` Russell O'Connor
2019-05-24 3:51 ` ZmnSCPxj
2019-05-24 4:15 ` ZmnSCPxj
2019-05-24 15:10 ` Russell O'Connor
2019-05-24 20:51 ` Jeremy
2019-05-24 23:07 ` Russell O'Connor
2019-05-25 1:08 ` Jeremy
2019-05-25 12:52 ` Russell O'Connor
2019-05-27 7:21 ` Anthony Towns
2019-05-28 3:41 ` ZmnSCPxj [this message]
2019-05-29 6:49 ` Russell O'Connor
2019-06-13 8:14 ` Tamas Blummer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='oUAmCZn8d8qxim0QgUJDaseoYn_52GuYm-1G88WRHmCe60t_pcbx_NL_Opn6HbEKklGuteRLbtEPVRC_JaNm9qJ_Opbbw3DkC0mLzTbXmWs=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox