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
|
Return-Path: <adan@stampery.co>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 076E1AF4
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 19 Oct 2017 13:41:56 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f47.google.com (mail-wm0-f47.google.com [74.125.82.47])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F3BE6165
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 19 Oct 2017 13:41:54 +0000 (UTC)
Received: by mail-wm0-f47.google.com with SMTP id k4so16513535wmc.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 19 Oct 2017 06:41:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stampery.co; s=google;
h=from:reply-to:subject:to:references:organization:message-id:date
:user-agent:mime-version:in-reply-to:content-language
:content-transfer-encoding;
bh=uRz5LmCf/uWxSuKx9ELGBoTO/6ZAPlWckQvwjFIle44=;
b=jQLVqBNnXxPs+t3vVuzZksKUTXljIWmMY+lBxck7PSstXJQbIASFIeqCQbPMYKz0uB
Ioccfl+sBk+8d/nasGTmMw6AbhOfWAT8zrQFw0176TuVUo5YsParGW+ZrYOt882nIiI2
lxI15of3/+upUe6upkUEbsevd7j1s9KCzLAsA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:from:reply-to:subject:to:references:organization
:message-id:date:user-agent:mime-version:in-reply-to
:content-language:content-transfer-encoding;
bh=uRz5LmCf/uWxSuKx9ELGBoTO/6ZAPlWckQvwjFIle44=;
b=DPv775tJv/lb6kj66p0FK7kXO/WwmHyRntOzZeP+MgIbQn4GJGBLNtQdpR5KGxAzeO
Fs3rBCAy7TF4GoWNOyCwElzm6EZ0FgrEKy6uBkL66anroRWx1+QiIIRd0bMbEZqeusmC
l0lTrmziIe0LQwuWqI4GV2FALI5kDKKNZ0lOHe/eFVDJYZcgG60ZLk0li7mO5x0wH1Lk
6AT9YgrUc3mMEDdGbn6+9Q7+VKLDqkFmuHLCOyu9D9yMjk7/BTIkvOknysiY2oTHXTb1
CRlGg2dDtmVaiot2cborHiwhlKWVzb/UVd40stn1BwWU6FbPIP0MMCeYZ0xbkTFMMwQe
hdcw==
X-Gm-Message-State: AMCzsaXWAw/V3rVBsQ7w6Mw8p/xNsaeYIXC7CksVszK8yZOfAgzWtHmO
71S2JptfcET2tMyT07q+EO/AeFXqP20=
X-Google-Smtp-Source: ABhQp+Ss6iuSPBl7Lbmf/q+x4anVv9KZh+vUTIQexhSJcAlHfTjzjrcyX7IeZaQiDx46NPSj2NZr0w==
X-Received: by 10.28.92.133 with SMTP id q127mr1613468wmb.26.1508420513165;
Thu, 19 Oct 2017 06:41:53 -0700 (PDT)
Received: from [192.168.1.42] (32.red-83-45-227.dynamicip.rima-tde.net.
[83.45.227.32])
by smtp.gmail.com with ESMTPSA id q7sm2082351wrg.97.2017.10.19.06.41.52
for <bitcoin-dev@lists.linuxfoundation.org>
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Thu, 19 Oct 2017 06:41:52 -0700 (PDT)
From: "=?UTF-8?Q?Ad=c3=a1n_S=c3=a1nchez_de_Pedro_Crespo?=" <adan@stampery.co>
X-Google-Original-From: =?UTF-8?Q?Ad=c3=a1n_S=c3=a1nchez_de_Pedro_Crespo?=
<adan@stampery.com>
Reply-To: adan@stampery.com
To: bitcoin-dev@lists.linuxfoundation.org
References: <CAH01uEtLhLEj5XOp_MDRii2dR8-zUu4fUsCd25mzLDtpD_fwYQ@mail.gmail.com>
Organization: Stampery
Message-ID: <40b6ef7b-f518-38cd-899a-8f301bc7ac3a@stampery.com>
Date: Thu, 19 Oct 2017 15:41:51 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <CAH01uEtLhLEj5XOp_MDRii2dR8-zUu4fUsCd25mzLDtpD_fwYQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=0.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=disabled
version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 19 Oct 2017 13:50:59 +0000
Subject: Re: [bitcoin-dev] Improving Scalability via Block Time Decrease
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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, 19 Oct 2017 13:41:56 -0000
Blockchains with fast confirmation times are currently believed to
suffer from reduced security due to a high stale rate.
As blocks take a certain time to propagate through the network, if miner
A mines a block and then miner B happens to mine another block before
miner A's block propagates to B, miner B's block will end up wasted and
will not "contribute to network security".
Furthermore, there is a centralization issue: if miner A is a mining
pool with 30% hashpower and B has 10% hashpower, A will have a risk of
producing a stale block 70% of the time (since the other 30% of the time
A produced the last block and so will get mining data immediately)
whereas B will have a risk of producing a stale block 90% of the time.
Thus, if the block interval is short enough for the stale rate
to be high, A will be substantially more efficient simply by virtue of
its size. With these two effects combined, blockchains which produce
blocks quickly are very likely to lead to one mining pool having a large
enough percentage of the network hashpower to have de facto control over
the mining process.
Another possible implication of reducing the average block time is that
block size should be reduced accordingly. In an hypothetical 5 minutes
block size Bitcoin blockchain, there would be twice the block space
available for miners to include transactions, which could lead to 2
immediate consequences: (1) the blockchain could grow up to twice the
rate, which is known to be bad for decentralization; and (2) transaction
fees might go down, making it cheaper for spammers to bloat our beloved
UTXO sets.
There have been numerous proposals that tried to overcome the downsides
of faster blocks, the most noteworthy probably being the "Greedy
Heaviest Observed Subtree" (GHOST) protocol:
http://www.cs.huji.ac.il/~yoni_sompo/pubs/15/btc_scalability_full.pdf
Personally, I can't see why Bitcoin would need or how could it even
benefit at all from faster blocks. Nevertheless, I would really love if
someone in the list who has already run the numbers could bring some
valid points on why 10 minutes is the optimal rate (other than "if it
ain't broke, don't fix it").
--
Adán Sánchez de Pedro Crespo
CTO, Stampery Inc.
San Francisco - Madrid
|
