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
|
Return-Path: <pieter.wuille@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 5DE35826
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 10 Aug 2015 21:01:07 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f182.google.com (mail-io0-f182.google.com
[209.85.223.182])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3F51D17A
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 10 Aug 2015 21:01:06 +0000 (UTC)
Received: by iodb91 with SMTP id b91so122733055iod.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 10 Aug 2015 14:01:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=Y2zj6Q5FvZ52Wma7HAS++L48H+e+2c8gOpJojXIbY9k=;
b=y1lL5fqq7Z1JDrIG4Sd4OFC+gUWOUdDzK928qoFp1GVEPyNgcOY9H/+nNVqxGVfSkS
NDyQRFgVsQ+eCWmEw25VjThtW7WFKGHW3kPKCnNX0j9Xv44ZjxBYMyVqkCTXtdsS71l4
RlngxhmfIRwoesLpzZ8XLxOw1KXgTqbEiPx8/DVQRwU0CKNivqdKca9fOC9lZ9ZDw8cz
jQWWySOnYBAtTp44w5e25JB1v5oUmHyfEaOi+KNieHe6UYzvHfKKWhpTAIXZUCxhPMWm
6qzLs+KvCQI4xl+CPKzpDsTwqD7rZboZ97zPISZ2cnOq6FIvTxRnmKlZAsVNviTYm1RT
7Ejg==
MIME-Version: 1.0
X-Received: by 10.107.37.142 with SMTP id l136mr23656042iol.126.1439240465621;
Mon, 10 Aug 2015 14:01:05 -0700 (PDT)
Received: by 10.36.77.201 with HTTP; Mon, 10 Aug 2015 14:01:05 -0700 (PDT)
Received: by 10.36.77.201 with HTTP; Mon, 10 Aug 2015 14:01:05 -0700 (PDT)
In-Reply-To: <CAKzdR-o7_A2N=-=3muXcs7ptnoO2d3wSBAMAziNGs7XjnceGBQ@mail.gmail.com>
References: <CAKzdR-o7_A2N=-=3muXcs7ptnoO2d3wSBAMAziNGs7XjnceGBQ@mail.gmail.com>
Date: Mon, 10 Aug 2015 23:01:05 +0200
Message-ID: <CAPg+sBjRFTZxOOg8ZUhTVqbZDJusZ4xyooRh1LcvwbBDSLu1oA@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Sergio Demian Lerner <sergio.d.lerner@gmail.com>
Content-Type: multipart/alternative; boundary=001a1140269ab329aa051cfb48e1
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>
Subject: Re: [bitcoin-dev] If you had a single chance to double the
transactions/second Bitcoin allows...
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: Mon, 10 Aug 2015 21:01:07 -0000
--001a1140269ab329aa051cfb48e1
Content-Type: text/plain; charset=UTF-8
On Aug 7, 2015 11:19 PM, "Sergio Demian Lerner via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> b. Reduce the block rate to a half (average 5 minute blocks)
>
> Suppose this is a one time hard fork. There no drastic technical problems
with any of them: "SPV" mining and the relay network has shown that block
propagation is not an issue for such as small change. Mining centralization
won't radically change for a 2x adjustment.
I don't understand this. All problems that result from propagation delay
are literally doubled by doing so. Centralization pressure results from the
ratio between propagation time and interblock time. Efficient propagation
algorithms like the relay network make this presumably grow sublinear with
larger blocks, but changing the interblock time affects it exactly
proportionally.
All problems that result from propagation delay are literally doubled by
doing this. Doubling the block size has a smaller effect. You may argue
that these centralization effects are small, but reducing the interblock
time has a stronger effect on them than the block size.
Also, you seem to consider SPV mining a good thing? It requires trust
between miners that know eachother, and fundamentally breaks the security
assumption of SPV clients... and if the propagation/interblock ratio was
lower, SPV mining would have less effect. I'd say it is exactly a result of
the centralization pressure we're trying to avoid.
--
Pieter
--001a1140269ab329aa051cfb48e1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">On Aug 7, 2015 11:19 PM, "Sergio Demian Lerner via bitc=
oin-dev" <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">=
bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br>
> b. Reduce the block rate to a half (average 5 minute blocks)<br>
><br>
> Suppose this is a one time hard fork. There no drastic technical probl=
ems with any of them: "SPV" mining and the relay network has show=
n that block propagation is not an issue for such as small change. Mining c=
entralization won't radically change for a 2x adjustment.=C2=A0</p>
<p dir=3D"ltr">I don't understand this. All problems that result from p=
ropagation delay are literally doubled by doing so. Centralization pressure=
results from the ratio between propagation time and interblock time. Effic=
ient propagation algorithms like the relay network make this presumably gro=
w sublinear with larger blocks, but changing the interblock time affects it=
exactly proportionally.</p>
<p dir=3D"ltr">All problems that result from propagation delay are literall=
y doubled by doing this. Doubling the block size has a smaller effect. You =
may argue that these centralization effects are small, but reducing the int=
erblock time has a stronger effect on them than the block size.</p>
<p dir=3D"ltr">Also, you seem to consider SPV mining a good thing? It requi=
res trust between miners that know eachother, and fundamentally breaks the =
security assumption of SPV clients... and if the propagation/interblock rat=
io was lower, SPV mining would have less effect. I'd say it is exactly =
a result of the centralization pressure we're trying to avoid.</p>
<p dir=3D"ltr">-- <br>
Pieter<br>
</p>
--001a1140269ab329aa051cfb48e1--
|
