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
|
Return-Path: <cserveny.tamas@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id CC61AD58
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 1 Sep 2017 18:16:05 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f54.google.com (mail-vk0-f54.google.com
[209.85.213.54])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6BE2BF8
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 1 Sep 2017 18:16:05 +0000 (UTC)
Received: by mail-vk0-f54.google.com with SMTP id x85so2697214vkx.5
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 01 Sep 2017 11:16:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
bh=KSNpEug/ZkRFdTGhd6UWF1HjfVLU87jNcHaX15p4zAg=;
b=L0xSSrFDjJhXlTMWWzNIeKxJYV4R8UnYHwXliE0aLRet0ve6We8sBOu1AjvOidtwYv
T5rIVjyRI7HF80aUn+Osbhsl/fjWO/iI+INlhQXe+fGZcJshOgYzpgQqXiUT2jLyW+7r
nozujLqwmUBdvThkFQP6aec56DPyXtSu/vpuR9ukT/Vrr3nYKrCF/7IKdCBtRQbnRKAS
Y6qW+Fk984QovFp+KUSDHsz4fhdUryV+ipnfl04WMDrvRwkaSWlB8iZob6zSmwvaXvH9
SEwMXadfh4nUzaOSB4nS7mii6YyBhzESUEI8c3AgCWxuJcfjphgJskGhXGT9GdTmDKMZ
oEVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to;
bh=KSNpEug/ZkRFdTGhd6UWF1HjfVLU87jNcHaX15p4zAg=;
b=dc0K/Ju2lJlB1bdsTozv16fczw/mROoxb6vpNZGU2QC7Fpka4Ua8vmDxzsPJ3eVha8
jZZi1xQ1MuuPEUonAekfs2scw0lr6WlgVfa1v4o+j+CUA/qzSlivkIYxtRw5YCDy21Df
4uAVIO9m4iK64qWuPQcCAZ+ltVGYeaShc2hpIRd5yzaR+3aH3j5O6ORdYWHAnSJHqjr4
U21B7LNcVfdngO7iCoPKsiYwZyE+oYwBOMT93gTtxVy1QHZ3/oSzfbR4lxYX6k3AKvvd
33oYHiTkV3XMbX+Genj+BF4ONpxJU1W09k6ARPjdXfwBtglz5NvDHwVb7Pcwx/7wwT76
RtBg==
X-Gm-Message-State: AHPjjUjtLO8nwTL3kLaFt8zcrWLvWHnrgfci0lkUOMzblkvJWg1dlWjT
UhMfYaJx1fB6SrmJTErvxMYXpZ7JfKwn
X-Google-Smtp-Source: ADKCNb6LN6WKHTUbPXNKjDAo/LHctz5tL+dXDYBjD1GsgA1LuokzP9Z6JYH98fsrCCGpLKx2JDB8Eqv4KxfBIW25l6A=
X-Received: by 10.31.49.200 with SMTP id x191mr1385267vkx.127.1504289764487;
Fri, 01 Sep 2017 11:16:04 -0700 (PDT)
MIME-Version: 1.0
References: <CACY+MSO8PM89VTtKfuZiQGvAs7a7R6_4mY+onhZh9KnvwxW2uw@mail.gmail.com>
<1570222.Uh686LP1o4@strawberry>
<CAGCathxjDsST6xD+CvKN_3md3UcWuKqgSvV+CjaTqS4gPaPGZg@mail.gmail.com>
In-Reply-To: <CAGCathxjDsST6xD+CvKN_3md3UcWuKqgSvV+CjaTqS4gPaPGZg@mail.gmail.com>
From: Cserveny Tamas <cserveny.tamas+bc@gmail.com>
Date: Fri, 01 Sep 2017 18:15:53 +0000
Message-ID: <CACY+MSOPWhTnR-ZR67T1a5ZU2w4pWa6FkXsGF3_C+n3gKFCPSA@mail.gmail.com>
To: Lucas Clemente Vella <lvella@gmail.com>, Tom Zander <tomz@freedommail.ch>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="001a1143e9280d3671055824c182"
X-Spam-Status: No, score=1.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU, FREEMAIL_FROM, FREEMAIL_REPLY, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE,
RCVD_IN_SORBS_SPAM autolearn=disabled version=3.3.1
X-Spam-Level: *
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Fri, 01 Sep 2017 18:26:59 +0000
Subject: Re: [bitcoin-dev] Horizontal scaling of blockchain
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: Fri, 01 Sep 2017 18:16:05 -0000
--001a1143e9280d3671055824c182
Content-Type: text/plain; charset="UTF-8"
Yes. I meant the single thread as an analogy, if a block is found, other
blocks are worthless. (more or less) Longest chain wins.
My line of though was, that currently the only way to scale with the
traffic (and lowering the fees) is increasing the block size (which is hard
as I learned from recent events), or reducing the complexity which is less
secure (most likely more controversial)
Splitting the chain is effectively increasing the block size, but without
the increased hashing and validation overhead.
The usage growth seems to be more of exponential rather than linear. Sooner
or later the block size will need to be 4 mb then 40 mb, then what is the
real limit? Otherwise waiting times and thus the fees will just grow
rapidly. I don't think that it is desirable.
With splitting the ledger, the block size can remain 1-2 mb for long time,
only new partitions needs to be added on a schedule. This would also make
better use of the hashing capacity.
Cheers,
Tamas
On Fri, Sep 1, 2017 at 7:15 PM Lucas Clemente Vella <lvella@gmail.com>
wrote:
> > The current chain is effectively single threaded.
>>
>> This is not true, since xthin/compactblocks have been introduced we
>> completely removed this bottle-neck.
>> The transactions will be validated continuously, in parallel and not just
>> when a block is found.
>>
>
> If I understood correctly, OP was not talking about the process inside a
> node being single threaded, but instead that the whole bitcoin distributed
> system behaves as single threaded computation. OP seems to be describing a
> system closer to what IOTA uses, by distributing among the miners the task
> of validating the transactions. Although, without more specific details, it
> is hard to judge the benefits.
>
> --
> Lucas Clemente Vella
> lvella@gmail.com
>
--001a1143e9280d3671055824c182
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Yes. I meant the single thread as an analogy, if a block i=
s found, other blocks are worthless. (more or less) Longest chain wins.<div=
><br></div><div>My line of though was, that currently the only way to scale=
with the traffic (and lowering the fees) is increasing the block size (whi=
ch is hard as I learned from recent events), or reducing the complexity whi=
ch is less secure (most likely more controversial)</div><div><br></div><div=
>Splitting the chain is effectively increasing the block size, but without =
the increased hashing and validation overhead.=C2=A0</div><div><br></div><d=
iv>The usage growth seems to be more of exponential rather than linear. Soo=
ner or later the block size will need to be 4 mb then 40 mb, then what is t=
he real limit? Otherwise waiting times and thus the fees will just grow rap=
idly. I don't think that it is desirable.</div><div><br></div><div>With=
splitting the ledger, the block size can remain 1-2 mb for long time, only=
new partitions needs to be added on a schedule. This would also make bette=
r use of the hashing capacity.</div><div><br></div><div>Cheers,<br></div><d=
iv><br></div><div>Tamas</div><div><br></div><div><div><br></div><div><br><d=
iv><br></div><div><br></div></div></div><br><div class=3D"gmail_quote"><div=
dir=3D"ltr">On Fri, Sep 1, 2017 at 7:15 PM Lucas Clemente Vella <<a hre=
f=3D"mailto:lvella@gmail.com" target=3D"_blank">lvella@gmail.com</a>> wr=
ote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D=
"gmail_extra"><div class=3D"gmail_quote"><span></span><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex"><span>
> The current chain is effectively single threaded.<br>
<br>
</span>This is not true, since xthin/compactblocks have been introduced we<=
br>
completely removed this bottle-neck.<br>
The transactions will be validated continuously, in parallel and not just<b=
r>
when a block is found.<br></blockquote><div><br></div></div></div></div><di=
v dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>If=
I understood correctly, OP was not talking about the process inside a node=
being single threaded, but instead that the whole bitcoin distributed syst=
em behaves as single threaded computation. OP seems to be describing a syst=
em closer to what IOTA uses, by distributing among the miners the task of v=
alidating the transactions. Although, without more specific details, it is =
hard to judge the benefits.<br></div><div>=C2=A0</div></div></div></div><di=
v dir=3D"ltr"><div class=3D"gmail_extra">-- <br><div class=3D"m_-5172599773=
912857920m_5361571732319184822gmail_signature" data-smartmail=3D"gmail_sign=
ature">Lucas Clemente Vella<br><a href=3D"mailto:lvella@gmail.com" target=
=3D"_blank">lvella@gmail.com</a></div>
</div></div></blockquote></div></div>
--001a1143e9280d3671055824c182--
|
