summaryrefslogtreecommitdiff
path: root/63/19a6910e9322ceae86c2275a5e5448c09ff461
blob: 53692f5651469dd5f505eede5a5bef697a899d87 (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
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
Return-Path: <bram@chia.net>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 68BEFC0012
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 16 Mar 2022 06:46:02 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 4796D40424
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 16 Mar 2022 06:46:02 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 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, HTML_MESSAGE=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=chia.net
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 IT9U_68TC-vQ
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 16 Mar 2022 06:46:01 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com
 [IPv6:2a00:1450:4864:20::235])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 0BD0E40138
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 16 Mar 2022 06:46:00 +0000 (UTC)
Received: by mail-lj1-x235.google.com with SMTP id g24so618467lja.7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 15 Mar 2022 23:46:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chia.net; s=google;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=RoPomhW5ep8V400tvu2QeRY4ib5kLhsNm0XS01c/FRc=;
 b=wuEXBLvooftOdGkvLyq/YDxR24zW6dTUMTO2CqtZiOGYw+tA/OI0OsVvDxFhLocgVV
 eQvNMSuvT86EZBUNQQolwdLFqouWav94feZFnw6lGpApyQmIn4dmsRrUKukIoI2kRHCN
 JuOx27DMRpX7Xt+X+cs9i2EudawDowrb0+Jm0VbfF0Ku7tFjn0qPPkRKMOR+D6u3NMrV
 zJk8Dzl7KxmdwAcqzlV97JqrExybkfs3x8CAU9guO2+D+NNXKhnCbtyl8kt1GVjTL4md
 XKOPLtm03kD6m5TRyFqLpnkAWNp0nc52plDBBiXvkjDE2L+9LqYGGulEaESi6mJMOQR3
 LljQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=RoPomhW5ep8V400tvu2QeRY4ib5kLhsNm0XS01c/FRc=;
 b=EoioUk0Oq8BOEyLwCDylwjMwHdaObCNLf0F2JpIJSJXy0+ykxQT4tlKVsOK5YouOpJ
 t9OuhyfpbTXdmMJPzGO16puJcp5qTiCgWa5cUSVZH+x0i1+E8kKKP0HNwFNoD2CQJU4G
 Ej/vqoTKuyJ7TVc3mpOvQ+ruDEWcRC/tlRI5v3ymL8vtszOWjYSUXc8XYHbdDYhb72Ob
 oKOpndLHG5PTGDxJFMHiQQ19BOn+YDslykhpj/rKS00mtFU70xWJP3BIBZXXg1CLrFwz
 9c7e6Uyltn0EO8blVBT4ZsvB8w3EpFtwh6rXAvcWOqNRqVv3UKQe6QWBiksD3wo2GuTR
 Y+qw==
X-Gm-Message-State: AOAM5302hJ6M0zuvsbVJ4WrZAB6Vg06J5glHrwTXbCahW9rOjuHZsJJa
 U+9w+aZ0hVrrvfUi6AkhphRVrZVCa9o97B6cg0rfoQ==
X-Google-Smtp-Source: ABdhPJym8OaLw8k7Db4bn/3XJVHH0U8RSVzccUSouB2xkNfuMYA4VHgtU7N9U/jOQYEQojzjvknundZ2D0a6C/3ybSs=
X-Received: by 2002:a2e:b5a7:0:b0:249:1e1f:dde9 with SMTP id
 f7-20020a2eb5a7000000b002491e1fdde9mr15156190ljn.45.1647413158844; Tue, 15
 Mar 2022 23:45:58 -0700 (PDT)
MIME-Version: 1.0
References: <uOr9bwW2C0lwMSiUOEie2rzyrA7uE4Rm7kVnU2FnF9jyMGjYDvN0WhDM6QbZ_XxNlu44WqE7meXBZAeHAd94DAWnYcSBOPuo4nb4UQp2Wmk=@protonmail.com>
 <CAHUJnBCrw0n_9=2gugMhTW6QCjStBFxEsGrF=BY9JX806OurXQ@mail.gmail.com>
 <20220308012719.GA6992@erisian.com.au>
 <CAHUJnBDR-zQa0uBRorWkVf7CO+oS-J3zJU7B8K9cA_+7vqa=Dg@mail.gmail.com>
 <20220310064717.GA7597@erisian.com.au>
In-Reply-To: <20220310064717.GA7597@erisian.com.au>
From: Bram Cohen <bram@chia.net>
Date: Tue, 15 Mar 2022 23:45:48 -0700
Message-ID: <CAHUJnBDX5_HkocD4DMT05g59aWyrYMt=dDEBS_3hraJMoVOSXA@mail.gmail.com>
To: Anthony Towns <aj@erisian.com.au>
Content-Type: multipart/alternative; boundary="00000000000021add405da504484"
X-Mailman-Approved-At: Wed, 16 Mar 2022 16:04:24 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] bitcoin scripting and lisp
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: Wed, 16 Mar 2022 06:46:02 -0000

--00000000000021add405da504484
Content-Type: text/plain; charset="UTF-8"

On Wed, Mar 9, 2022 at 10:47 PM Anthony Towns <aj@erisian.com.au> wrote:

>
> To redo the singleton pattern in bitcoin's context, I think you'd have
> to pass in both the full tx you're spending (to be able to get the
> txid of its parent) and the full tx of its parent (to be able to get
> the scriptPubKey that your utxo spent) which seems klunky but at least
> possible (you'd be able to drop the witness data at least; without that
> every tx would be including the entire history of the singleton).
>

Yes that's the idea. Since the parent transaction is in the blockchain it
could be pulled in automatically without having to charge vbytes for it.


> If softfork is just doing a best effort for whatever opcodes it knows
> about, and otherwise succeeding, then it has to succeed, and your
> script/output has become anyone-can-spend.
>

That can be alleviated by when things call untrusted code they can wrap it
in a guard which can be the soft fork opcode itself.


>
> On the other hand, if you could tell the softfork op that you only wanted
> ops up-to-and-including the 118 softfork, then it could reject fakeopcode
> and fail the script, which I think gives the desirable behaviour.
>

A simple approach to versioning like that may be more expedient. Soft
forking in CLVM isn't implemented yet.

--00000000000021add405da504484
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Wed, Mar 9, 2022 at 10:47 PM Anthony T=
owns &lt;<a href=3D"mailto:aj@erisian.com.au">aj@erisian.com.au</a>&gt; wro=
te:<br></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex"><br>
To redo the singleton pattern in bitcoin&#39;s context, I think you&#39;d h=
ave<br>
to pass in both the full tx you&#39;re spending (to be able to get the<br>
txid of its parent) and the full tx of its parent (to be able to get<br>
the scriptPubKey that your utxo spent) which seems klunky but at least<br>
possible (you&#39;d be able to drop the witness data at least; without that=
<br>
every tx would be including the entire history of the singleton).<br></bloc=
kquote><div><br></div><div>Yes that&#39;s the idea. Since the parent transa=
ction is in the blockchain it could be pulled in automatically without havi=
ng to charge vbytes for it.</div><div>=C2=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex">If softfork is just doing a best effort for whatev=
er opcodes it knows<br>
about, and otherwise succeeding, then it has to succeed, and your<br>
script/output has become anyone-can-spend.<br></blockquote><div><br></div><=
div>That can be alleviated by when things call untrusted code they can wrap=
 it in a guard which can be the soft fork opcode itself.</div><div>=C2=A0</=
div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
On the other hand, if you could tell the softfork op that you only wanted<b=
r>
ops up-to-and-including the 118 softfork, then it could reject fakeopcode<b=
r>
and fail the script, which I think gives the desirable behaviour.<br></bloc=
kquote><div><br></div><div>A simple approach to versioning like that may be=
 more expedient. Soft forking in CLVM isn&#39;t implemented yet.</div></div=
></div>

--00000000000021add405da504484--