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
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
|
Return-Path: <earonesty@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 03D939BA
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 6 Apr 2017 03:11:56 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f175.google.com (mail-qk0-f175.google.com
[209.85.220.175])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 32A00136
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 6 Apr 2017 03:11:55 +0000 (UTC)
Received: by mail-qk0-f175.google.com with SMTP id p22so27477579qka.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 05 Apr 2017 20:11:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:reply-to:in-reply-to:references:from:date:message-id
:subject:to:cc;
bh=cWb9X+qSye/XYZUDxDKJ2zoaqbcUHH8YS3cfSxHc/dI=;
b=Dqpv6kbZNqJXCzJtIi9/LR42F2m8Tgk2wG2TfDF/97Vg9U6FQgO6MDIPPkk25v4fGE
imEwTrOZPd1LcQGtllDM/3fOnUvCTM7WI/Wce7I4J3t3R2++/V/2+R7KWbFLofmKgK4A
kZWNC9tCVXJbp/AKPxG9L6dP01SjFXjl6ychoKx/iPhFfjJJe4qAenbvnP0FGHTJKuRs
F8VoW//ws7qTKTdUdRAdGx2x7QzOrPYI9Pg0PeSt3nc8ofey1hEfHnPaw1szXboThuuT
5LdFyUCopHRTvge5cMeGLrvNoysPuSC3FMqK4Bsbiu8uEJj/kU6oF+9tuKQ0YjQxE+hc
H7UA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:reply-to:in-reply-to:references
:from:date:message-id:subject:to:cc;
bh=cWb9X+qSye/XYZUDxDKJ2zoaqbcUHH8YS3cfSxHc/dI=;
b=YEMNMv7pRI0344KrR35As01jTerr48hLmONA22jHr6Jd0BHvnrJciR2S3t7cvfImMt
x+KKwdT3nfQ/UDfnxMO8vS0HDzsSI4pXOXiDbto0VdExe2tesiv+FFhA26AyPdHtPKV4
u/34hejo0NqIqiZ/44udpe0CDTQjNMCM4Tph3sOh6h8MJclOtQEM6+PGMEje2+AM62Bs
KKHY06IPsjj7Su2T8P6usEbBgFXDpZtsytHwbOVSufxfai3w0xJnsJEL0+C0Myc0Dp0e
/nddVo5QvHL+7eORn1mPsa7iAbmjFHYWqJxeR7iW4HGUie4gdJdx+QX/1OR6i9X6vGrY
TIaQ==
X-Gm-Message-State: AFeK/H07xTBGBaNn5MDPwX7FotQmLAWsZlv0YPZOc+MYz0gQHLWkKHoVThR/IPIbP/AYOUr+CC+nCM5hPr/98w==
X-Received: by 10.55.33.207 with SMTP id f76mr24221579qki.85.1491448314353;
Wed, 05 Apr 2017 20:11:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.55.113 with HTTP; Wed, 5 Apr 2017 20:11:53 -0700 (PDT)
Received: by 10.200.55.113 with HTTP; Wed, 5 Apr 2017 20:11:53 -0700 (PDT)
Reply-To: erik@q32.com
In-Reply-To: <20170406024910.GA1271@savin.petertodd.org>
References: <CAAS2fgR84898xD0nyq7ykJnB7qkdoCJYnFg6z5WZEUu0+-=mMA@mail.gmail.com>
<20170406023123.GA1071@savin.petertodd.org>
<CA+KqGkqSxeAUZFVFqM_QkEWcGFHgZXwGuOE==7HpXp1+D_Tj3Q@mail.gmail.com>
<20170406024910.GA1271@savin.petertodd.org>
From: Erik Aronesty <earonesty@gmail.com>
Date: Wed, 5 Apr 2017 23:11:53 -0400
Message-ID: <CAJowKgL_BfJyyp=z6PB3mj+KBy0y9ParspbbnhoOTA0Cfr6C6g@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=001a1144dcd6fa66d1054c76ded2
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE,
RCVD_IN_SORBS_SPAM autolearn=no 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, 06 Apr 2017 03:15:58 +0000
Subject: Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the
Bitcoin POW function
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: Thu, 06 Apr 2017 03:11:56 -0000
--001a1144dcd6fa66d1054c76ded2
Content-Type: text/plain; charset=UTF-8
If the primary purpose of pow is to destroy value, then a masked proof of
burn to an expanded address that assigns the private key holder the right
to mine only in the next Nth block would be sufficient. Expanding the
address space so that addresses can only be proven invalid only with the
private key. Miners can then not trivially game the system by excluding
tx...without killing the entire system. ( Like POW ... miners lose many
burns since only one valid proof is deterministically selected. Difficult
adjusted upward based on the number of valid proofs per block.)
The other part of "real POW" is that miners take *time* to mine. Proof of
destroyed value us not sufficient. Proof of time spent is critical....
something even a masked burn cannot provide.
On Apr 5, 2017 10:49 PM, "Peter Todd via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Wed, Apr 05, 2017 at 07:39:08PM -0700, Bram Cohen wrote:
> > On Wed, Apr 5, 2017 at 7:31 PM, Peter Todd via bitcoin-dev <
> > > While I'm in favour of blocking covert usage of ASICBOOST, there's
> every
> > > reason
> > > to block non-covert usage of it as well. In a low margin business like
> > > mining,
> > > the advatange it gives is enormous - quite possibly 10x your profit
> margin
> > > -
> > > and given that barrier free access to being able to purchase ASICs is
> > > already
> > > an archilles heal for Bitcoin there is every reason to eliminate this
> legal
> > > vulnerability. Additionally, it's a technical vulnerability as well: we
> > > want
> > > getting into the ASIC manufacturing and design business to have as low
> > > barriers
> > > to entry as is feasible, and the ASICBOOST exploit significantly
> increases
> > > the
> > > minimum capital requirements to do so.
> > >
> >
> > Asicboost also has the problem that it isn't treating the hashing as a
> > black box, and thus has impacts on what gets mined. In particular it
> > creates an incentive to make blocks smaller. That's a very unwanted
> effect,
> > and anything like it should be engineered out on principle.
>
> Agreed! There's no benefit to Bitcoin for having it - one way or the other
> miners are going to destroy ~12BTC/block worth of energy. Meanwhile it
> appears
> to have lead to something like a year of stupid political bullshit based
> on a
> secret advantage - there's no reason to invite a repeat of this episode.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--001a1144dcd6fa66d1054c76ded2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto">If the primary purpose of pow is to destroy value, then a=
masked proof of burn to an expanded address that assigns the private key h=
older the right to mine only in the next Nth block would be sufficient.=C2=
=A0 Expanding the address space so that addresses can only be proven invali=
d only with the private key.=C2=A0 Miners can then not trivially game the s=
ystem by excluding tx...without killing the entire system. =C2=A0( Like POW=
... miners lose many burns since only one valid proof is deterministically=
selected. Difficult adjusted upward based on the number of valid proofs pe=
r block.)<div dir=3D"auto"><br></div><div dir=3D"auto">The other part of &q=
uot;real POW" is that miners take *time* to mine.=C2=A0 Proof of destr=
oyed value us not sufficient.=C2=A0 Proof of time spent is critical.... som=
ething even a masked burn cannot provide.</div></div><div class=3D"gmail_ex=
tra"><br><div class=3D"gmail_quote">On Apr 5, 2017 10:49 PM, "Peter To=
dd via bitcoin-dev" <<a href=3D"mailto:bitcoin-dev@lists.linuxfound=
ation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br type=3D"=
attribution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex">On Wed, Apr 05, 2017 at 07:39:0=
8PM -0700, Bram Cohen wrote:<br>
> On Wed, Apr 5, 2017 at 7:31 PM, Peter Todd via bitcoin-dev <<br>
> > While I'm in favour of blocking covert usage of ASICBOOST, th=
ere's every<br>
> > reason<br>
> > to block non-covert usage of it as well. In a low margin business=
like<br>
> > mining,<br>
> > the advatange it gives is enormous - quite possibly 10x your prof=
it margin<br>
> > -<br>
> > and given that barrier free access to being able to purchase ASIC=
s is<br>
> > already<br>
> > an archilles heal for Bitcoin there is every reason to eliminate =
this legal<br>
> > vulnerability. Additionally, it's a technical vulnerability a=
s well: we<br>
> > want<br>
> > getting into the ASIC manufacturing and design business to have a=
s low<br>
> > barriers<br>
> > to entry as is feasible, and the ASICBOOST exploit significantly =
increases<br>
> > the<br>
> > minimum capital requirements to do so.<br>
> ><br>
><br>
> Asicboost also has the problem that it isn't treating the hashing =
as a<br>
> black box, and thus has impacts on what gets mined. In particular it<b=
r>
> creates an incentive to make blocks smaller. That's a very unwante=
d effect,<br>
> and anything like it should be engineered out on principle.<br>
<br>
Agreed! There's no benefit to Bitcoin for having it - one way or the ot=
her<br>
miners are going to destroy ~12BTC/block worth of energy. Meanwhile it appe=
ars<br>
to have lead to something like a year of stupid political bullshit based on=
a<br>
secret advantage - there's no reason to invite a repeat of this episode=
.<br>
<br>
--<br>
<a href=3D"https://petertodd.org" rel=3D"noreferrer" target=3D"_blank">http=
s://petertodd.org</a> 'peter'[:-1]@<a href=3D"http://petertodd.org"=
rel=3D"noreferrer" target=3D"_blank">petertodd.org</a><br>
<br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div></div>
--001a1144dcd6fa66d1054c76ded2--
|
