summaryrefslogtreecommitdiff
path: root/96/fe402bab3c7f27229e21b8f54d9644ec2f92fb
blob: 1e9f756aefb00c2b8cc48311647af814b771ecab (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
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
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
Return-Path: <m@ib.tc>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id B713CC0051
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  8 Oct 2020 15:21:08 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by hemlock.osuosl.org (Postfix) with ESMTP id A581C8729B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  8 Oct 2020 15:21:08 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from hemlock.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id aG-w+uKWQYFg
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  8 Oct 2020 15:21:04 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com
 [209.85.221.47])
 by hemlock.osuosl.org (Postfix) with ESMTPS id 3D99D874B0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  8 Oct 2020 15:21:04 +0000 (UTC)
Received: by mail-wr1-f47.google.com with SMTP id h7so7074929wre.4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 08 Oct 2020 08:21:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ib.tc; s=google;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=9/Vb0zAd4WK8gBBdewifPNmyuRZl6300QGeBHAY5kLg=;
 b=dIW328UYvY74/879gYP5u45Iv6ZAOCqMAwWlB7jCdhe+9I+rDb92+rS4PKWKrJNAmn
 0+wfzzYQ8DfjrC1xFS6PP5i7CwvH/HMa/4kdKk6y0RacBO7sLMBVxP46cri56cIi0Kx9
 QpkeW5WoG57trOcc5NxO/ObM5T3ua6y7DNARJqBY2mkDlw3zVK8+dUFCL1Zo2dV6PpoF
 OkMFFtwsWKJGZVOE2Cj/WJ5eGThXbdnvloRsgfi6u+KdkltjzwmFivH12RjUCizPvjTH
 HSZXwil/rbpBXATIBoxL67o4uvDJgzChWKmTbgnE1S8pnjwEhZ4MrWctOGnPMoffjD4W
 lTlg==
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;
 bh=9/Vb0zAd4WK8gBBdewifPNmyuRZl6300QGeBHAY5kLg=;
 b=Cf4OwUtqkyvPxzob4V9f0U3hKQYDz7TNzG+/kb4RLW3x1vkF5FPrv9r0tTm2vRKfRc
 pMKUYhyyyttc10N0Zt9UTmJu1+UmnLFwPTwZMzZXjROH1taT0kza+dMni6Tbj1wmgxTX
 kT5mJlXxeJj+MaHKfEoTyht1isvX+vtIdJwCkC+8qxsu0diSAjPpq7vwp5ql3y6rZ7j+
 /JAuqDFP0lEdesMaFbAdZx1TVNiGnf6TaC7/yw789nCuxCR8sXFEF7GgsYVbn1fyQSEX
 HchUaNFm/wKizr082pB9Vg1iG4XfGfuKc7rGyxwJ9NLi5zquyg4zCHGV2MVbsKIgm6sX
 W5bQ==
X-Gm-Message-State: AOAM531d3KI6zM3Qk5jee2JBTyYFbNPfI7sxS5aK4TWVJ+snyBaqbuO+
 sclNNL7YoNANWHJ3STHNp0R9SMNc/a3cXUvosv8hXg==
X-Google-Smtp-Source: ABdhPJwAuxwM4a6Qo6agTvZLHE2i2XVKoJpd6yGJAYL5cbqSkJYsP5PXd3T0Oh4lWqZEaax55dDyTyq1bOYey5mBgwE=
X-Received: by 2002:adf:fc4e:: with SMTP id e14mr9955651wrs.329.1602170462571; 
 Thu, 08 Oct 2020 08:21:02 -0700 (PDT)
MIME-Version: 1.0
References: <CALFqKjTY6d2nQtUe-NyyKJEYcWKEj1mfdQfAzKkB-NRDwYD5JQ@mail.gmail.com>
 <STSmfzWKGGPx0yJ9ysTPbDw-KpvlBLmr9R5IPDogPw0FRzG0BZ7Bk_NeWiwPUYw6Nhrqkq5DlrmtN9T3vXE83p_JH6LDizMTWZ9MCQSaous=@protonmail.com>
In-Reply-To: <STSmfzWKGGPx0yJ9ysTPbDw-KpvlBLmr9R5IPDogPw0FRzG0BZ7Bk_NeWiwPUYw6Nhrqkq5DlrmtN9T3vXE83p_JH6LDizMTWZ9MCQSaous=@protonmail.com>
From: Mike Brooks <m@ib.tc>
Date: Thu, 8 Oct 2020 16:05:05 -0700
Message-ID: <CALFqKjRL9c_z5o-35zkXQ0kxzgYmiPinhk8zqhTWRCqKqDfkag@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000004aa52105b12a61b1"
X-Mailman-Approved-At: Thu, 08 Oct 2020 15:53:46 +0000
Subject: Re: [bitcoin-dev] Progress on Miner Withholding - FPNC
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: Thu, 08 Oct 2020 15:21:08 -0000

--0000000000004aa52105b12a61b1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Very interesting,

Block mixing did not resolve the selfish mining that is currently observed
on the network.  This mitigation was only intended to limit the maximum
impact of waiting for a 2nd block to be produced.

Rebalancing the selfish-mining incentives with FPNC and a faster block
creation time is the single best thing we can do to decentralize mining
efforts.  It will also produce a better network.



On Wed, Oct 7, 2020 at 6:40 PM ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Good morning all,
>
> >
> > Below is a novel discussion on block-withholding attacks and FPNC. Thes=
e
> are two very simple changes being proposed here that will
> dramatically impact the network for the better.
> >
> > But first of all, I'd like to say that the idea for FPNC came out of a
> conversation with ZmnSCPxj's in regards to re-org stability.  When I had
> proposed blockchain pointers with the PubRef opcode, he took the time to
> explain to me concerns around re-orgs and why it is a bigger problem than=
 I
> initially had thought =E2=80=94 and I greatly appreciate this detail.   A=
fter
> touching base with ZmnSCPxj and Greg Maxwell there is an overwhelming vie=
w
> that the current problems that face the network outweigh any theoretical
> ones.
> >
> > Currently the elephant in the room is the miner withholding
> attack. There is an unintended incentive to hold onto blocks because
> keeping knowledge of this coinbase private gives a greedy miner more time
> to calculate the next block.  Major mining pools are actively employing
> this strategy because winning two blocks in a row has a much greater payo=
ff
> than common robbery. This unfair advantage happens each time a new block =
is
> found, and provides a kind of home-field advantage for large pools, and
> contributes to a more centralized network. This odd feature of the bitcoi=
n
> protocol provides a material incentive to delay transactions and encourag=
es
> the formation of disagreements. In a sense, withholding is a deception of
> the computational power of a miner, and by extension a deception of their
> influence within the electorate.  In effect, other miners are forced to
> work harder, and when they are successful in finding a 2nd solution of th=
e
> same height =E2=80=94 no one benefits. Disagreement on the bitcoin networ=
k is not
> good for the environment, or for the users, or for honest miners, but is
> ideal for dishonest miners looking for an advantage.
>
> This is my understanding:
>
> The selfish mining attack described above was already presented and known
> about **many years** ago, with the solution presented here:
> https://www.cs.cornell.edu/~ie53/publications/btcProcFC.pdf
>
> The solution was later determined to actually raise the needed threshhold
> to 33%, not 25% in the paper.
>
> That solution is what is used in the network today.
>
> Implementing floating-point Nakamoto Consensus removes the solution
> presented in the paper, and therefore risks reintroducing the selfish
> mining attack.
>
> Therefore, floating-point Nakamoto Consensus is a hard NAK.
>
>
> Regards,
> ZmnSCPxj
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">Very interesting,<div><br></div><div>Block mixing did not =
resolve the selfish mining that is currently observed on the network.=C2=A0=
 This mitigation was only=C2=A0intended to limit the maximum impact of wait=
ing for a 2nd block to be produced.</div><div><br></div><div>Rebalancing=C2=
=A0the selfish-mining incentives with FPNC and a faster block creation=C2=
=A0time is the single best thing we can do to decentralize mining efforts.=
=C2=A0 It will also produce a better network.</div><div><br></div></div><di=
v dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote"><di=
v dir=3D"ltr" class=3D"gmail_attr">On Wed, Oct 7, 2020 at 6:40 PM ZmnSCPxj =
via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org=
" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br=
></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left:1px solid rgb(204,204,204);padding-left:1ex">Good morning all,<=
br>
<br>
&gt;<br>
&gt; Below is a novel discussion=C2=A0on block-withholding=C2=A0attacks and=
 FPNC. These are=C2=A0two very simple changes being proposed here that will=
 dramatically=C2=A0impact the network for the better.<br>
&gt;<br>
&gt; But first of all, I&#39;d like to say that the idea for FPNC came out =
of a conversation=C2=A0with ZmnSCPxj&#39;s in regards to=C2=A0re-org stabil=
ity.=C2=A0 When I had proposed blockchain pointers with the PubRef opcode, =
he took the time to explain to me concerns around re-orgs and why it is a b=
igger problem than I initially had thought=C2=A0=E2=80=94 and I greatly app=
reciate this detail.=C2=A0 =C2=A0After touching base with ZmnSCPxj and Greg=
 Maxwell there is an overwhelming view that the current problems that face =
the network outweigh any theoretical ones.<br>
&gt;<br>
&gt; Currently the elephant in the room is the miner withholding attack.=C2=
=A0There is an unintended incentive to hold onto blocks because keeping kno=
wledge of this coinbase private gives a greedy miner more time to calculate=
 the next block.=C2=A0 Major mining pools are actively employing this strat=
egy because winning two blocks in a row has a much greater payoff than comm=
on robbery. This unfair advantage=C2=A0happens each time a=C2=A0new block i=
s found, and provides a kind of home-field advantage for large pools, and c=
ontributes to a more centralized network. This odd feature of the bitcoin p=
rotocol provides a material incentive to delay transactions and encourages =
the formation of disagreements. In a sense, withholding is a deception of t=
he computational power of a miner, and by extension a deception of their in=
fluence within the electorate.=C2=A0 In effect, other miners are forced to =
work harder,=C2=A0and when they are successful in finding a 2nd solution of=
 the same height=C2=A0=E2=80=94 no one benefits. Disagreement on the bitcoi=
n network is not good for the environment, or for the users, or for honest =
miners, but is ideal for dishonest miners looking for an advantage.<br>
<br>
This is my understanding:<br>
<br>
The selfish mining attack described above was already presented and known a=
bout **many years** ago, with the solution presented here: <a href=3D"https=
://www.cs.cornell.edu/~ie53/publications/btcProcFC.pdf" rel=3D"noreferrer" =
target=3D"_blank">https://www.cs.cornell.edu/~ie53/publications/btcProcFC.p=
df</a><br>
<br>
The solution was later determined to actually raise the needed threshhold t=
o 33%, not 25% in the paper.<br>
<br>
That solution is what is used in the network today.<br>
<br>
Implementing floating-point Nakamoto Consensus removes the solution present=
ed in the paper, and therefore risks reintroducing the selfish mining attac=
k.<br>
<br>
Therefore, floating-point Nakamoto Consensus is a hard NAK.<br>
<br>
<br>
Regards,<br>
ZmnSCPxj<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div></div>

--0000000000004aa52105b12a61b1--