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
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
|
Return-Path: <christopher.gilliard@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 02749C0019
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 17 Apr 2021 03:58:11 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id CDFBE40143
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 17 Apr 2021 03:58:11 +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, FREEMAIL_FROM=0.001,
HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=gmail.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 BGPeWtJmxowo
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 17 Apr 2021 03:58:07 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com
[IPv6:2607:f8b0:4864:20::333])
by smtp2.osuosl.org (Postfix) with ESMTPS id A766D40139
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 17 Apr 2021 03:58:07 +0000 (UTC)
Received: by mail-ot1-x333.google.com with SMTP id
c8-20020a9d78480000b0290289e9d1b7bcso13496472otm.4
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 16 Apr 2021 20:58:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=mjNBJaCjAKzRK9QKeWpfxvx4hx5GXHaIXN+dWJnT3HU=;
b=c2lF+AfMCqJim/Wm+GmXDvfGo6DrRrBMGgp83atpw/isazlKylrDVrl0hs2QYpAFk+
JPbP1u7N97II3sTIbBE3ocIeRcaSk23heMp6sgsk8kZEkV2HQkLwcMv8orDfH3nTyymg
WDiRtz4bUHgrStMAgAegnoibPG8eFQ9KtuEfxfTghBChp7dliEkug9F2rJJNJsF4Wp+l
lY3tu4NH93g7h5t94axh1yvX+4LP08yHq3VIhhoeQkyNpyO3T2nxidrCSN9qw9ikOGcQ
paSNzW/6ecCvP/baeOXPw2bwlAnvXjp1s21r/L742bkRMGrs1zdHi3kPWJ8eIhFy3Oef
eRog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=mjNBJaCjAKzRK9QKeWpfxvx4hx5GXHaIXN+dWJnT3HU=;
b=HP5c95E3oPCy/RXmZvATkmvGHhouDqCkHH51SYQ04QHrUUNhGO8lVW608bzGHc77H0
DoBPQHdT3iae6JWuSOVUnVDvQLi1nJxv+v61wJMYZsk55nsQLS8AdXrIDGRZEmOla4Js
EJ7ELfy5oaCCV094sfAaAQvxt0RVQS6gstIxEnlc/H+P0gJEW0dJu2Y10oy/NwE0SJVn
+9YvmZc71X7eNxJqNZ7fib7hxLOl4yFhopsgW38vhYF7nD/m1HcCeGwCVlLsX4e6I5XC
MbjEQgYHDbI4kAh5ZdzPjs7rWGAbz7qYmJpmZjrgOY9MdOpo+GEPEVhl9SdAT+FHekD5
3t5w==
X-Gm-Message-State: AOAM533PnDT81X5xCio3ZgtFw+woqOS2dy0RkUL/UdQJBsgo4tQ4OPxL
gq43FWczGcN8pUv7a+nYzQLydSgnkjVdYLJJeWc=
X-Google-Smtp-Source: ABdhPJw08Vtni0u5kpaLfhaKLWapXdXBaFA0YltqgC3u0izG2ms3fz9Ia5AONCCmgtQapYmb1dYWz+De7ud7xDF2MP0=
X-Received: by 2002:a05:6830:2083:: with SMTP id
y3mr6106240otq.73.1618631886686;
Fri, 16 Apr 2021 20:58:06 -0700 (PDT)
MIME-Version: 1.0
References: <CAK=nyAxOa8fsVfxucH7WTTMn25BCzgQ28h_sNsunedpCoRXjjQ@mail.gmail.com>
<CAMZUoKmR6ZU6mAgEhKDD5cTMuja_OC0_Sz3x4UND=E-g1PkgsQ@mail.gmail.com>
<CAK=nyAz5+yMUA=XDcunA1eeachSisaJoYE2_yzTLj=B0r4=w5A@mail.gmail.com>
<iU2J5dWMIgqAf312ZCNmx38_hcYsKrcuqx84kniWeEdb0wP8jPZPvwHK3P-q1yvmQ5OtdMCwMFqPgwmsL7BUfE8PGUlrxW4rOM3slwHun3E=@protonmail.com>
In-Reply-To: <iU2J5dWMIgqAf312ZCNmx38_hcYsKrcuqx84kniWeEdb0wP8jPZPvwHK3P-q1yvmQ5OtdMCwMFqPgwmsL7BUfE8PGUlrxW4rOM3slwHun3E=@protonmail.com>
From: Christopher Gilliard <christopher.gilliard@gmail.com>
Date: Sat, 17 Apr 2021 03:57:55 +0000
Message-ID: <CAK=nyAxJ_XYDhTE6pNHqWOQ-cLgqc_f-fbQ+EHTkxyiYOhOPUQ@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="000000000000a0cd3605c0231a2c"
X-Mailman-Approved-At: Sat, 17 Apr 2021 08:29:00 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF
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, 17 Apr 2021 03:58:12 -0000
--000000000000a0cd3605c0231a2c
Content-Type: text/plain; charset="UTF-8"
Thanks ZmnSCPxj. Yes, I agree there are many ways to embed arbitrary data
in the blockchain and it's not feasible to block all of them. That is why
it's important to, at the same time as limiting the OP_RETURN to one per
block, also propose and implement a layer 2 solution for timestamping
so people have a clear and simple upgrade path. That is what I will be
discussing in one of the BIPs I intend to release early next week.
On Fri, Apr 16, 2021 at 11:52 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
> Good morning Christopher,
>
> > >> But more importantly, adding limitations on OP_RETURN transactions is
> not helpful. Users who want to embed arbitrary data in their transactions
> can always do so by encoding their data inside the values of legacy
> multi-signature scriptpubkeys (pubkeys can be generated without knowing the
> private key in order to encode non-key related data). Not only can users
> do this, users have done this in the past. However, this behaviour is
> problematic because such multi-signature "data" scriptpubkeys are
> indistinguishable from "real" multisignature scriptpubkeys, and thus must
> be kept in the UTXO set. This differs from outputs using OP_RETURN which
> are provably unspendable, and therefore can be safely omitted from the UTXO
> set.
> >
> > This sounds like a good justification to remove the legacy
> multi-signature capabilities as well.
>
> The same technique can be used on P2PKH as well --- the "pubkey hash" need
> not be a hash of a public key, it can be a 20-byte commitment, or even an
> ASCII message like "ZmnSCPxj is the best" (20 characters, I counted).
> There is nothing that *can* check if the hash of a public key is indeed
> the hash of a public key unless you actually reveal the public key.
>
> If you need a 32-byte commitment, a P2WSH would work --- again the "script
> hash" need not be a hash of a script, it can be any 32-byte commitment.
>
> In all these cases you have to waste 547 satoshi, but that tends to be
> small compared to tx fees currently.
>
> Regards,
> ZmnSCPxj
>
--000000000000a0cd3605c0231a2c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Thanks ZmnSCPxj. Yes, I agree there are many ways to embed=
arbitrary data in the blockchain and it's not feasible to block all of=
them. That is why it's important to, at the same time as limiting the =
OP_RETURN to one per block, also propose and implement a layer 2 solution f=
or timestamping so=C2=A0people have a clear=C2=A0and simple upgrade path. T=
hat is what I will be discussing in one of the BIPs I=C2=A0intend to releas=
e early next week.</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" cla=
ss=3D"gmail_attr">On Fri, Apr 16, 2021 at 11:52 PM ZmnSCPxj <<a href=3D"=
mailto:ZmnSCPxj@protonmail.com">ZmnSCPxj@protonmail.com</a>> wrote:<br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex">Good morning Christo=
pher,<br>
<br>
> >> But more importantly, adding limitations on OP_RETURN transac=
tions is not helpful.=C2=A0 Users who want to embed arbitrary data in their=
transactions can always do so by encoding their data inside the values of =
legacy multi-signature scriptpubkeys (pubkeys can be generated without know=
ing the private key in order to encode non-key related data).=C2=A0 Not onl=
y can users do this, users have done this in the past.=C2=A0 However, this =
behaviour is problematic because such multi-signature "data" scri=
ptpubkeys are indistinguishable from "real" multisignature script=
pubkeys, and thus must be kept in the UTXO set.=C2=A0 This differs from out=
puts using OP_RETURN which are provably unspendable, and therefore can be s=
afely omitted from the UTXO set.<br>
><br>
> This sounds like a good justification to remove the legacy multi-signa=
ture capabilities as well.<br>
<br>
The same technique can be used on P2PKH as well --- the "pubkey hash&q=
uot; need not be a hash of a public key, it can be a 20-byte commitment, or=
even an ASCII message like "ZmnSCPxj is the best" (20 characters=
, I counted).<br>
There is nothing that *can* check if the hash of a public key is indeed the=
hash of a public key unless you actually reveal the public key.<br>
<br>
If you need a 32-byte commitment, a P2WSH would work --- again the "sc=
ript hash" need not be a hash of a script, it can be any 32-byte commi=
tment.<br>
<br>
In all these cases you have to waste 547 satoshi, but that tends to be smal=
l compared to tx fees currently.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
</blockquote></div>
--000000000000a0cd3605c0231a2c--
|
