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
|
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 AA35C116A
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 26 Dec 2015 17:38:13 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pf0-f177.google.com (mail-pf0-f177.google.com
[209.85.192.177])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 30034EC
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 26 Dec 2015 17:38:13 +0000 (UTC)
Received: by mail-pf0-f177.google.com with SMTP id 65so48085651pff.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 26 Dec 2015 09:38:13 -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:cc:message-id;
bh=HotRQ+LbWgL3dBF0Y2CC1sW70W/522MuOhiiTolpUKU=;
b=zCc+a5HA6rl4ZMAS+4UD28xcw0urNZtdhzwAlGUxsmHwvqJXvq6oeSqR4H7NWHVXa8
PxuM/5EO2KbpAlEtHyFMxD9VavF1ygNErSeM1dGKC7QNiL2sEZYTc4RV65YNVjfAe2gd
CLzs2bTyM0Y00ICmHfZS2PlNjjPaT35qWKqcMiR6iXZffkOWXnB6fxzH72i8Fd4kQq2+
DwPG1lZ32uRq7+XCzrrBmUMcujg8N9U5iCDt3yzOuownNNyVgspeO+RVM0/aFMwfbD8H
EpVrllXg36xZmj/Zgm3tCpFJS+FwqGRZMYxWCKYdVL5cCEyvVD7evpUDQK07UWJl1edY
AMjQ==
X-Received: by 10.98.68.198 with SMTP id m67mr67059640pfi.56.1451151492911;
Sat, 26 Dec 2015 09:38:12 -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
19sm30508371pfj.16.2015.12.26.09.38.11
(version=TLSv1/SSLv3 cipher=OTHER);
Sat, 26 Dec 2015 09:38:12 -0800 (PST)
User-Agent: K-9 Mail for Android
In-Reply-To: <CABm2gDp4ac=E+T-FT=ZQPnW_ao2GdF1QOg8tROYoV=QKypQS1g@mail.gmail.com>
References: <20151220132842.GA25481@muck>
<ema8a70574-c28e-4c43-a1e3-5f2f4df7d3a2@platinum>
<CABm2gDp4ac=E+T-FT=ZQPnW_ao2GdF1QOg8tROYoV=QKypQS1g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----HFR2LPWF5LFY0JZ58R59BNQBCVCIGR"
Content-Transfer-Encoding: 8bit
From: Eric Lombrozo <elombrozo@gmail.com>
Date: Sat, 26 Dec 2015 09:38:33 -0800
To: =?ISO-8859-1?Q?Jorge_Tim=F3n?= <jtimon@jtimon.cc>
Message-ID: <EC9193E8-DEC6-413F-A9AC-903E26E51824@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
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 17:38:13 -0000
------HFR2LPWF5LFY0JZ58R59BNQBCVCIGR
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
charset=UTF-8
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, the difficulty is lowered so that if the second PoW difficulty were to be kept 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 same 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 these 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ón" <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
>time
>is increased, it's not clear to me that the pow per block would
>necessarily
>be higher.
>What am I missing?
------HFR2LPWF5LFY0JZ58R59BNQBCVCIGR
Content-Type: text/html;
charset=utf-8
Content-Transfer-Encoding: 8bit
<html><head></head><body>For simplicity, assume total network hashpower is constant. Also, assume the soft fork activates at the beginning of a retarget period.<br>
<br>
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, the difficulty is lowered so that if the second PoW difficulty were to be kept constant the block 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 stabilize 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 so once again more hashes on average are required to find a block by the same 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 simplistic.<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 these 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="gmail_quote">On December 26, 2015 7:33:53 AM PST, "Jorge Timón" <jtimon@jtimon.cc> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<p dir="ltr"><br />
On Dec 26, 2015 9:24 AM, "Eric Lombrozo via bitcoin-dev" <<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br />
<br />
> 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.<br />
> </p>
<p dir="ltr">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 time is increased, it's not clear to me that the pow per block would necessarily be higher.<br />
What am I missing?<br />
</p>
</blockquote></div></body></html>
------HFR2LPWF5LFY0JZ58R59BNQBCVCIGR--
|
