summaryrefslogtreecommitdiff
path: root/c4/58f6655d32168caaa0b7231b1f962218131083
blob: 07f0ff9cba5a726eac2d1857749b1455fe49005f (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id CF3961B38
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	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 <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
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <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