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
|
Return-Path: <elombrozo@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 6D3EDD8C
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 26 Dec 2015 18:29:44 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com
[209.85.220.44])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4F1D7EC
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 26 Dec 2015 18:29:43 +0000 (UTC)
Received: by mail-pa0-f44.google.com with SMTP id ho8so1927801pac.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 26 Dec 2015 10:29:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=user-agent:in-reply-to:references:mime-version:content-type
:content-transfer-encoding:subject:from:date:to:message-id;
bh=+B4iM0VeFZnx8rDTwedZMbgyXOsGqs6i61xos3lw+Us=;
b=Dqc1K7ILRIHmnRkj26un5Voeg1dF/N2wXhKJ5CvMl9ddA71PxACbVqvMsqnFJ6asS6
XzL1h71ruxNcRdIj0hFUKDOZCqCXvQiB6KGe1RRJ2Ie2GZpC6rI+0lNON/QaJ1f6Ra/d
yHyj6zEJyIrfef6zmLSifB7gaSBy+P68z+pAf6sfTDbGh+1uRtepfvNNtgUQBn7gz3k9
DCPTqb+Qa+1jc70/r+2UV7LsrfBq+dVjcoGxWZqMjswkJgtrGjSSgPMK5eJV2Ds6BtIC
qM2V9tVv0LKpRoVgRnve70QBsFjWtzHVtLG+NOkrjHNgl4h+lZt/pxJpF82J2ZHiw0MK
vX1Q==
X-Received: by 10.66.197.131 with SMTP id iu3mr46149101pac.57.1451154583041;
Sat, 26 Dec 2015 10:29:43 -0800 (PST)
Received: from [192.168.1.104] (cpe-76-167-237-202.san.res.rr.com.
[76.167.237.202]) by smtp.gmail.com with ESMTPSA id
x75sm4849291pfi.95.2015.12.26.10.29.41
(version=TLSv1/SSLv3 cipher=OTHER);
Sat, 26 Dec 2015 10:29:42 -0800 (PST)
User-Agent: K-9 Mail for Android
In-Reply-To: <CAE-z3OUrCFkVQ+1th-BjkZf1YEhPjub7TA_2J-CRNmCs6Bb7Dg@mail.gmail.com>
References: <20151220132842.GA25481@muck>
<ema8a70574-c28e-4c43-a1e3-5f2f4df7d3a2@platinum>
<CAE-z3OUrCFkVQ+1th-BjkZf1YEhPjub7TA_2J-CRNmCs6Bb7Dg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----U2SMO4RF2VGYL5P2FQL866XPQYZ48L"
Content-Transfer-Encoding: 8bit
From: Eric Lombrozo <elombrozo@gmail.com>
Date: Sat, 26 Dec 2015 10:30:04 -0800
To: Tier Nolan <tier.nolan@gmail.com>,
Tier Nolan via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>,
Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <99F2E7CA-42BF-432F-B371-F00DA145B817@gmail.com>
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,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
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:29:44 -0000
------U2SMO4RF2VGYL5P2FQL866XPQYZ48L
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
charset=UTF-8
I should have stated that we're assuming the actual total hashrate remains constant. Obviously this is not what would actually happen - the rest of the post discusses ways to counter the economic forces at play pushing total hashrate down using only soft forks. The increased variance is still unaccounted for (pool operators would have to deal with this somehow)...and we still have larger block intervals even with compensation. And the practicality of deployment and usability are clearly problematic, to understate things.
It's merely an exercise seeking the theoretical limit of what's actually possible to do with a soft fork.
On December 26, 2015 8:09:18 AM PST, Tier Nolan via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>On Sat, Dec 26, 2015 at 8:23 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.
>>
>
>
>No, the re-target compensates so that the number of blocks in the last
>two
>weeks is 2016. If a soft fork forces miners to throw away 25% of their
>blocks, then the difficulty will drop by 75% to keep things balanced.
>Throwing away 75% of blocks has the same effect on difficulty as
>destroying
>75% of mining hardware.
>
>The block interval will only increase until the next re-target.
>
>Slowly increasing the fraction of blocks which are thrown away gives
>the
>re-target algorithm time to adjust, so it is another advantage.
>
>If the rule was instantly changed so that 95% of blocks were thrown
>away,
>then there could be up to 40 weeks until the next retarget and that
>would
>give 200 minute block times until the adjustment.
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>bitcoin-dev mailing list
>bitcoin-dev@lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
------U2SMO4RF2VGYL5P2FQL866XPQYZ48L
Content-Type: text/html;
charset=utf-8
Content-Transfer-Encoding: 8bit
<html><head></head><body>I should have stated that we're assuming the actual total hashrate remains constant. Obviously this is not what would actually happen - the rest of the post discusses ways to counter the economic forces at play pushing total hashrate down using only soft forks. The increased variance is still unaccounted for (pool operators would have to deal with this somehow)...and we still have larger block intervals even with compensation. And the practicality of deployment and usability are clearly problematic, to understate things.<br>
<br>
It's merely an exercise seeking the theoretical limit of what's actually possible to do with a soft fork.<br><br><div class="gmail_quote">On December 26, 2015 8:09:18 AM PST, Tier Nolan via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div dir="ltr"><br /><div class="gmail_extra"><br /><div class="gmail_quote">On Sat, Dec 26, 2015 at 8:23 AM, Eric Lombrozo via bitcoin-dev <span dir="ltr"><<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br /><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><span class=""></span><div><span><div>
<div>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.</div>
</div></span></div></div></blockquote><div><br /><br /></div><div>No, the re-target compensates so that the number of blocks in the last two weeks is 2016. If a soft fork forces miners to throw away 25% of their blocks, then the difficulty will drop by 75% to keep things balanced. Throwing away 75% of blocks has the same effect on difficulty as destroying 75% of mining hardware.<br /><br /></div><div>The block interval will only increase until the next re-target.<br /><br />Slowly increasing the fraction of blocks which are thrown away gives the re-target algorithm time to adjust, so it is another advantage. <br /><br />If the rule was instantly changed so that 95% of blocks were thrown away, then there could be up to 40 weeks until the next retarget and that would give 200 minute block times until the adjustment.<br /></div></div></div></div>
<p style="margin-top: 2.5em; margin-bottom: 1em; border-bottom: 1px solid #000"></p><pre class="k9mail"><hr /><br />bitcoin-dev mailing list<br />bitcoin-dev@lists.linuxfoundation.org<br /><a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br /></pre></blockquote></div></body></html>
------U2SMO4RF2VGYL5P2FQL866XPQYZ48L--
|
