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
|
Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id AC79DF43
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 26 Dec 2015 18:02:02 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f49.google.com (mail-vk0-f49.google.com
[209.85.213.49])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BC010EC
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 26 Dec 2015 18:02:00 +0000 (UTC)
Received: by mail-vk0-f49.google.com with SMTP id k1so38218111vkb.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 26 Dec 2015 10:02:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=jtimon-cc.20150623.gappssmtp.com; s=20150623;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=rt0RhQc+ILv4m2RAWdilNLGvTlk578nNRSSdAabVnFQ=;
b=ifdeN5Heq2OMk3+BZiMd83UCZXD+lC/44O3IjFCVDJ+1Oxmeho5c4zEeSfjNv1iAlv
KDLTPmhP3wEKs4ZuBRLLo1QCNV9l2vFbx+pEaFx+bsUbLIPdDnJzpLrDPzX15R3XRchz
HeWugBlfIt+japWlpuBwvitJvKBbWN85m/woMSEBHcydoecRJ1Q7lzVDOiXSmIRalxCq
qWJxculvHuU+bW68aEVOKV/jIarva1wvFIeKEaBZLJLtBPMjGiSRHfjBLQSIRjh/zdxi
spggRCN9Lwx4oydjkMznRxlKpsZIzXKZRPTGb2aoaU8v9hS50rTeyneWGRO/DwJS/q2k
wwNA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=rt0RhQc+ILv4m2RAWdilNLGvTlk578nNRSSdAabVnFQ=;
b=Hua2D+NIZtfuXXyXD8yz7FwC2FCZkkeyqNtaem+bH6Y+FvtPFFcEnNbH0w7iYpKZA5
GXF3KMSd7tX95pPVNryX0MqUpFwGPQhNGn61Ip9xO//HMjOAzdtvbe2judE605W1zyHM
8z4eVuDDnK/cSGG5TAFNCX2Wskg9pVxp9EoDUc2+NgvBIeS7UhjcDodEHWHQEDm1mDN8
wG72wHQTklO+qWznXCor3VsHkSfW03x79ojNPAQFi4fxq3/3mbod+MCoCmUyY7cpY82b
sqFXBM03E5qKNRkDphTlbaLuz3vvEFIhkgKf9pP4i4oFUzms/ci3+Zno4JIubMueH9pM
VJEA==
X-Gm-Message-State: ALoCoQkx9e6ku7+XmQ4sDNI/IG8SPzP3do9dMhGXGoI8V/Vu+/iTHIW50qAycP3r3r8ADNe6rLijYM6jvMPhakVGgreZ369TTQ==
MIME-Version: 1.0
X-Received: by 10.31.6.131 with SMTP id 125mr29482665vkg.140.1451152919896;
Sat, 26 Dec 2015 10:01:59 -0800 (PST)
Received: by 10.31.141.73 with HTTP; Sat, 26 Dec 2015 10:01:59 -0800 (PST)
Received: by 10.31.141.73 with HTTP; Sat, 26 Dec 2015 10:01:59 -0800 (PST)
In-Reply-To: <EC9193E8-DEC6-413F-A9AC-903E26E51824@gmail.com>
References: <20151220132842.GA25481@muck>
<ema8a70574-c28e-4c43-a1e3-5f2f4df7d3a2@platinum>
<CABm2gDp4ac=E+T-FT=ZQPnW_ao2GdF1QOg8tROYoV=QKypQS1g@mail.gmail.com>
<EC9193E8-DEC6-413F-A9AC-903E26E51824@gmail.com>
Date: Sat, 26 Dec 2015 19:01:59 +0100
Message-ID: <CABm2gDrkvsShE1Vbc9KVTTeFzjJJJrGj605pRxoOAWMwpMWn1w@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Eric Lombrozo <elombrozo@gmail.com>
Content-Type: multipart/alternative; boundary=001a1143da624e396d0527d0de34
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>, nbvfour@gmail.com
Subject: Re: [bitcoin-dev] We need to fix the block withholding attack
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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, 26 Dec 2015 18:02:02 -0000
--001a1143da624e396d0527d0de34
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
The hashpower is a function of the block reward (subsidy + fees): it's
economically irrational to have costs greater than the reward (better just
turn off your miners) and in a perfect competition (a theoretical model)
profits tend to zero. That is, the costs tend to equal revenue (block
reward).
On Dec 26, 2015 6:38 PM, "Eric Lombrozo" <elombrozo@gmail.com> wrote:
> For simplicity, assume total network hashpower is constant. Also, assume
> the soft fork activates at the beginning of a retarget period.
>
> At the moment the soft fork activates, the effective difficulty is
> increased (by adding a second independent PoW check that must also be
> satisfied) which means more hashes on average (and proportionally more
> time) are required to find a block. At the end of the retarget period, th=
e
> difficulty is lowered so that if the second PoW difficulty were to be kep=
t
> constant the block interval would again average 10 mins.
>
> If we were to keep the second PoW difficulty constant, we would restore
> the same total PoW-to-time-unit ratio and the retarget difficulty would
> stabilize again so each block would once more require the same number of
> hashes (and same amount of time) on average as before.
>
> But we don't keep the second PoW difficulty constant - we increase it so
> once again more hashes on average are required to find a block by the sam=
e
> proportion as before. And we keep doing this.
>
> Now, the assumption that hashpower is constant is obviously unrealistic.
> If this is your bone of contention, then yes, I agree my model is overly
> simplistic.
>
> My larger point was to explore the extent of what's possible with only a
> soft fork - and we can actually go pretty far and even compensate for the=
se
> economic shifts by increasing block size and rewards. The whole thing is
> clearly a huge mess - and I wouldn't recommend actually doing it.
>
>
>
> On December 26, 2015 7:33:53 AM PST, "Jorge Tim=C3=B3n" <jtimon@jtimon.cc=
>
> wrote:
>>
>>
>> On Dec 26, 2015 9:24 AM, "Eric Lombrozo via bitcoin-dev" <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> > Unfortunately, this also means longer confirmation times, lower
>> throughput, and lower miner revenue. Note, however, that confirmations
>> would (on average) represent more PoW, so fewer confirmations would be
>> required to achieve the same level of security.
>> >
>>
>> I'm not sure I understand this. If mining revenue per unit of time drops=
,
>> total pow per unit of time should also drop. Even if the inter-block tim=
e
>> is increased, it's not clear to me that the pow per block would necessar=
ily
>> be higher.
>> What am I missing?
>>
>
--001a1143da624e396d0527d0de34
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">The hashpower is a function of the block reward (subsidy + f=
ees): it's economically irrational to have costs greater than the rewar=
d (better just turn off your miners) and in a perfect competition (a theore=
tical model) profits tend to zero. That is, the costs tend to equal revenue=
(block reward).<br>
</p>
<div class=3D"gmail_quote">On Dec 26, 2015 6:38 PM, "Eric Lombrozo&quo=
t; <<a href=3D"mailto:elombrozo@gmail.com">elombrozo@gmail.com</a>> w=
rote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>For simpl=
icity, assume total network hashpower is constant. Also, assume the soft fo=
rk activates at the beginning of a retarget period.<br>
<br>
At the moment the soft fork activates, the effective difficulty is increase=
d (by adding a second independent PoW check that must also be satisfied) wh=
ich means more hashes on average (and proportionally more time) are require=
d to find a block. At the end of the retarget period, the difficulty is lo=
wered so that if the second PoW difficulty were to be kept constant the blo=
ck interval would again average 10 mins.<br>
<br>
If we were to keep the second PoW difficulty constant, we would restore the=
same total PoW-to-time-unit ratio and the retarget difficulty would stabil=
ize again so each block would once more require the same number of hashes (=
and same amount of time) on average as before.<br>
<br>
But we don't keep the second PoW difficulty constant - we increase it s=
o once again more hashes on average are required to find a block by the sam=
e proportion as before. And we keep doing this.<br>
<br>
Now, the assumption that hashpower is constant is obviously unrealistic. If=
this is your bone of contention, then yes, I agree my model is overly simp=
listic.<br>
<br>
My larger point was to explore the extent of what's possible with only =
a soft fork - and we can actually go pretty far and even compensate for the=
se economic shifts by increasing block size and rewards. The whole thing is=
clearly a huge mess - and I wouldn't recommend actually doing it.<br>
<br>
<br><br><div class=3D"gmail_quote">On December 26, 2015 7:33:53 AM PST, &qu=
ot;Jorge Tim=C3=B3n" <jtimon@jtimon.cc> wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">
<p dir=3D"ltr"><br>
On Dec 26, 2015 9:24 AM, "Eric Lombrozo via bitcoin-dev" <<a h=
ref=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitc=
oin-dev@lists.linuxfoundation.org</a>> wrote:<br>
=C2=A0<br>
> Unfortunately, this also means longer confirmation times, lower throug=
hput, and lower miner revenue. Note, however, that confirmations would (on =
average) represent more PoW, so fewer confirmations would be required to ac=
hieve the same level of security.<br>
> =C2=A0</p>
<p dir=3D"ltr">I'm not sure I understand this. If mining revenue per un=
it of time drops, total pow per unit of time should also drop. Even if the =
inter-block time is increased, it's not clear to me that the pow per bl=
ock would necessarily be higher.<br>
What am I missing?<br>
</p>
</blockquote></div></div></blockquote></div>
--001a1143da624e396d0527d0de34--
|
