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
116
117
118
119
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 47186C000B
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 5 Mar 2022 23:02:51 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 2CB2E4055A
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 5 Mar 2022 23:02:51 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level:
X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
FROM_LOCAL_NOVOWEL=0.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=protonmail.com
Received: from smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 3zp2MjNQgtSd
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 5 Mar 2022 23:02:50 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-40138.protonmail.ch (mail-40138.protonmail.ch
[185.70.40.138])
by smtp2.osuosl.org (Postfix) with ESMTPS id 3FBDB40558
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 5 Mar 2022 23:02:50 +0000 (UTC)
Date: Sat, 05 Mar 2022 23:02:41 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1646521367;
bh=IMwvsSLZndB7k32vCMMwUgkfxcjGHtosP7RgZZ6wBds=;
h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To:
References:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
Message-ID;
b=TUEMt1qbX6KjR/XrfoTOAFYXazwJI26g1G80ipRY1dpZUnujBPAKA867F7t5no6QK
L+AytOCTrtR4CCBylYP+fieu8gDTL3bSrbKmN4Ds2tiRO3PFOF5GhyoPiyUbuZ6rG+
4LYppxIcl3QYweZ+aTtBeaZPprItcw/tPTOAYUWuYFFAZEuiKpiK0qF9zxyLvfliza
kkDOuFEC/kdarrWOwZLgmcJjoZQmJdJH9wmgLmLrLri9ZJUUboL6CuJXLdb6Uy+mNr
Gqw/HV7joQWp5vv+ssYsXeYEl01CYtojawsjXp0zfrsgzuDHc1dot357ADGxuBa1ST
oPe3HFKGqgB7g==
To: Billy Tetrud <billy.tetrud@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <1zAD-_yaVAjRfYOQmNn_lh1cIQ9yxtR_TpLpHfl3A8TbtTpHEpduMloN72b-zI8U4HjrXRCHBBee16Ly89OAZJohfJuewWNCCHuacBN5TE8=@protonmail.com>
In-Reply-To: <CAGpPWDawAQShRU4OYcVnOE+qmHQv79ahwhMeyALF8iwjkZ_sOg@mail.gmail.com>
References: <rcWu5FJZQGCdQeFZSUKV2AylHwmlTYPWAnxvN-FP8lER3qFBLIYLPVH4-r0js0k6_Xy_TwxA3jWXZC15jFbAafNb_vnr3a54ZMrgAeTz6vM=@protonmail.com>
<CAGpPWDawAQShRU4OYcVnOE+qmHQv79ahwhMeyALF8iwjkZ_sOg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] `OP_FOLD`: A Looping Construct For Bitcoin SCRIPT
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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: Sat, 05 Mar 2022 23:02:51 -0000
Good morning Billy,
> It sounds like the primary benefit of op_fold is bandwidth savings. Progr=
amming as compression. But as you mentioned, any common script could be imp=
lemented as a Simplicity jet. In a world where Bitcoin implements jets, op_=
fold would really only be useful for scripts that can't use jets, which wou=
ld basically be scripts that aren't very often used. But that inherently li=
mits the usefulness of the opcode. So in practice, I think it's likely that=
jets cover the vast majority of use cases that op fold would otherwise hav=
e.
I suppose the point would be --- how often *can* we add new jets?
Are new jets consensus critical?
If a new jet is released but nobody else has upgraded, how bad is my securi=
ty if I use the new jet?
Do I need to debate `LOT` *again* if I want to propose a new jet?
> A potential benefit of op fold is that people could implement smaller scr=
ipts without buy-in from a relay level change in Bitcoin. However, even thi=
s could be done with jets. For example, you could implement a consensus cha=
nge to add a transaction type that declares a new script fragment to keep a=
count of, and if the script fragment is used enough within a timeframe (eg=
10000 blocks) then it can thereafter be referenced by an id like a jet cou=
ld be. I'm sure someone's thought about this kind of thing before, but such=
a thing would really relegate the compression abilities of op fold to just=
the most uncommon of scripts.=C2=A0
>
> > *=C2=A0We should provide more *general* operations.=C2=A0Users should t=
hen combine those operations to their=C2=A0specific needs.
> > * We should provide operations that *do more*.=C2=A0Users should identi=
fy their most important needs so=C2=A0we can implement them on the blockcha=
in layer.
>
> That's a useful way to frame this kind of problem. I think the answer is,=
as it often is, somewhere in between. Generalization future-proofs your sy=
stem. But at the same time, the boundary conditions of that generalized fun=
ctionality should still be very well understood before being added to Bitco=
in. The more general, the harder to understand the boundaries. So imo we sh=
ould be implementing the most general opcodes that we are able to reason fu=
lly about and come to a consensus on. Following that last constraint might =
lead to not choosing very general opcodes.
Yes, that latter part is what I am trying to target with `OP_FOLD`.
As I point out, given the restrictions I am proposing, `OP_FOLD` (and any b=
ounded loop construct with similar restrictions) is implementable in curren=
t Bitcoin SCRIPT, so it is not an increase in attack surface.
Regards,
ZmnSCPxj
|
