summaryrefslogtreecommitdiff
path: root/ae/3027923b27ca39ea44431fc21b1486b58cd9b8
blob: 43da8f67d02c290fdb8eeaf4d25ef97e5b8b2b39 (plain)
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
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
Return-Path: <contashk18@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 85713892
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 12 Mar 2017 09:51:14 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ua0-f194.google.com (mail-ua0-f194.google.com
	[209.85.217.194])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A45EFA1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 12 Mar 2017 09:51:13 +0000 (UTC)
Received: by mail-ua0-f194.google.com with SMTP id u30so17907887uau.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 12 Mar 2017 01:51:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:from:date:message-id:subject:to;
	bh=SQbh9R38egBgtRgvmo9LrAh0vkmNtLfs8QXayrfZYaw=;
	b=LpMLVfvnLIjrK37aJh56YuAh75l3Xq44W6lwsacHS8hL3gqbZrRmR/MXIjX6BMLLfB
	ApxGVEL29x7qausXSMzZJ452teLWiIt05muCHaVAwyKfUTaA7d8XT9d1tyghRu3FBv86
	9rKotvxiC55JzOUMKiDXc0V4sqtl9f/RbL9ft8ba8fqXmDBYoNzjiaEf71QTqGXXEG6/
	DfnAqE3ZA6hbMO2f07uzdOxhv4J7eo2uL9T0/Qnk5q7Y4HS0X3810V84VbDh+j5DjT2D
	u36ZkQBjvrbqeBZSgklXirQEVIG3WiR3j1DlXE0nvnK8lKCeDymsrc5y5p+JDr8A5f5N
	qohg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
	bh=SQbh9R38egBgtRgvmo9LrAh0vkmNtLfs8QXayrfZYaw=;
	b=LKuCHEEEWee1KXW5O+Fp+vRIYYQeJvblqx5fU/aijrtKPBlV0jUw08XugNsyiC/NEd
	qHBOcLqVsUbXRDFI/O3pYbSppMw0ys4UjjdHy48NIchNikhWzQc0EAR/75OrTKPZQpSb
	f7Rdb4qrSDrV/sp/UTkq8ECprkUm4rsdKvvCl95U6okYaXy9Sck/VDXyn518dIrEoGcu
	93noXVf6WHobGVuWs4JN8T7MrPOqRIrAK7qlII4eFoJsEGv7qejGiJRzeCL7Lb68QQve
	xx+fdgDAdNV+fcaf/h5QEnzGvyY49StCJpKs+3aXsY6/4/o2LDJVPMFq2jFXVkglyQxC
	oyVQ==
X-Gm-Message-State: AMke39kLUvY4du5CkP4v1n27gmhBZC2fASOBzmeNZHTI9ifjt2LIftBPDK4LtjAPHLC4grl6Fg4HcQOSgTSFBw==
X-Received: by 10.176.86.29 with SMTP id y29mr11020769uaa.74.1489312272525;
	Sun, 12 Mar 2017 01:51:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.103.86.79 with HTTP; Sun, 12 Mar 2017 01:51:12 -0800 (PST)
From: ashish khandekar <contashk18@gmail.com>
Date: Sun, 12 Mar 2017 15:21:12 +0530
Message-ID: <CAFaEF9KJD7rVOALiaN6uNNzcL_u8V8uX2BLiNaTJUk98pqot=g@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=f403045dd55af6af3a054a858836
X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
	HTML_MESSAGE, RCVD_IN_DNSWL_NONE,
	RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Sun, 12 Mar 2017 14:31:15 +0000
Subject: [bitcoin-dev] Solution for blockchain congestion and determination
 of block size by bitcoin network/protocol itself.
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: Sun, 12 Mar 2017 09:51:14 -0000

--f403045dd55af6af3a054a858836
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

BLOCKCHAIN CONGESTION =E2=80=93 A SOLUTION AND PRE-EMPTIVE MEASURES FOR THE=
 FUTURE



This document is an idea for helping the bitcoin block chain get
uncongested, provide enough space for transactions to get included in
blocks easily, and give the bitcoin network the power to defend itself
against any stress tests or spam attacks in the future.



The current maximum size of a block in the bitcoin protocol is 1mb.This has
created a =E2=80=9Cfee market=E2=80=9D allowing those who can send high tra=
nsaction fees
only to use bitcoin easily, making those who use even a slight lower fee to
wait for transactions to get confirmed by miners, sometimes it take hours
but sometimes it can scale up to a few days, this creates a difficulty for
merchants who use bitcoin to operate with ease, new people who are adapting
to bitcoin, and those unaware of the developments in the bitcoin community
confused in why transactions aren=E2=80=99t getting confirmed as they used =
to.



Bitcoin is a highly versatile. From its price being directly influenced by
its demand and supply to the amount of work done to keep the network safe
a.k.a. mining. Over the years both have changed dramatically but one thing
which has stayed constant is the size of the block, which is 1mb. The limit
of 1mb creates only a finite number of transactions to get confirmed even
if used to the brim, leaving out other transactions and creating a backlog
of transaction to be carried forward indefinitely.



Bitcoin=E2=80=99s verification system, mining, has a dynamic difficulty cal=
culation
rate, which means every 2016 blocks or 2 weeks the difficulty changes
making mining little bit easy or a bit difficult, but keeping the same
maximum output of 1mb per block, so this means every 2 weeks on 2016mb
worth of transactions can get verified assuming all blocks are filled to
the brim, any amount of excess transactions would not get verified due to
lack of space and would get carried over to the next cycle, over a period
of time this becomes a massive amount and has led to the current blockchain
congestion.



A unique solution is to let the bitcoin network change the maximum block
size as per the prevailing network conditions, this solution borrows some
aspects of both the demand and supply factor and dynamic change of network
difficulty (amount of work done to verify transactions).



This would be achieved by tracking the volume of the total size of
transactions done between 2 consecutive network difficulty changes and
dividing it by 2016, the number of blocks mined between 2 consecutive
network difficulty changes. The resulting answer would be rounded up to the
nearest kb and then compared to the previous block size, the higher between
the two would be taken as the new maximum block size. The extra space would
be helpful if a malicious attacker tries to create a lot of small dust
transactions and flood the network. Let us take a look at a  example of how
it would affect the bitcoin network in a real life scenario.



Dynamic block size calculation (B) =3D Total size of transactions from
previous network difficulty change(ST) / 2016

We compare this with the current block size and the higher is accepted as
new block size.



For example purposes the block numbers have been changed for easy
understanding.

If during cycle 1, block number 1 to block number 2016 the total size of
transactions is 1608mb,recalculating it with the dynamic block size
algorithm would give the following result:

Dynamic block size calculation (B) =3D ST/2016

1608/2016=3D0.79761905       which is 797kb

We compare this with the current block size which is 1mb (current block
size in real life) and the higher of the two becomes the block size for the
next cycle.

During cycle 2, block number 2017 to block number 4032 the total size of
transactions is 2260mb, recalculating it with the dynamic block size
algorithm would give the following result:

Dynamic block size calculation (B) =3D ST/2016

2260/2016=3D1.12103175       which is 1.2mb

We compare this with the current block size which is 1mb and the higher of
the two becomes the block size for the next cycle, in this case 1.2 mb
blocks would be new block size.



The above examples can be repeated indefinitely allowing the network to
adjust the block size automatically. The dynamic block size is to be
calculated at the same time as the network difficulty is changed.

To avoid orphaning of blocks and very small blocks a minimum block size
should also be taken into effect, the minimum size of the block should be
in the range of 30-60% of the maximum block size; this measure would also
stop the propagation of very small blocks which aren=E2=80=99t verifying
transactions and helping the network grow.



THE END

Any questions ?

Mail me at: contashk18@gmail.com

--f403045dd55af6af3a054a858836
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><p class=3D"MsoNormal" align=3D"center" style=3D"text-alig=
n:center">BLOCKCHAIN CONGESTION
=E2=80=93 A SOLUTION AND PRE-EMPTIVE MEASURES FOR THE FUTURE</p>

<p class=3D"MsoNormal" align=3D"center" style=3D"text-align:center"><span>=
=C2=A0</span></p>

<p class=3D"MsoNormal" align=3D"center" style=3D"text-align:center">This do=
cument is an
idea for helping the bitcoin block chain get uncongested, provide enough sp=
ace
for transactions to get included in blocks easily, and give the bitcoin net=
work
the power to defend itself against any stress tests or spam attacks in the
future.</p>

<p class=3D"MsoNormal" align=3D"center" style=3D"text-align:center"><span>=
=C2=A0</span></p>

<p class=3D"MsoNormal" align=3D"center" style=3D"text-align:center">The cur=
rent maximum
size of a block in the bitcoin protocol is 1mb.This has created a =E2=80=9C=
fee market=E2=80=9D
allowing those who can send high transaction fees only to use bitcoin easil=
y,
making those who use even a slight lower fee to wait for transactions to ge=
t
confirmed by miners, sometimes it take hours but sometimes it can scale up =
to a
few days, this creates a difficulty for merchants who use bitcoin to operat=
e
with ease, new people who are adapting to bitcoin, and those unaware of the=
 developments
in the bitcoin community confused in why transactions aren=E2=80=99t gettin=
g confirmed
as they used to.</p>

<p class=3D"MsoNormal" align=3D"center" style=3D"text-align:center"><span>=
=C2=A0</span></p>

<p class=3D"MsoNormal" align=3D"center" style=3D"text-align:center">Bitcoin=
 is a highly
versatile. From its price being directly influenced by its demand and suppl=
y to
the amount of work done to keep the network safe a.k.a. mining. Over the ye=
ars
both have changed dramatically but one thing which has stayed constant is t=
he
size of the block, which is 1mb. The limit of 1mb creates only a finite num=
ber
of transactions to get confirmed even if used to the brim, leaving out othe=
r
transactions and creating a backlog of transaction to be carried forward
indefinitely.</p>

<p class=3D"MsoNormal" align=3D"center" style=3D"text-align:center"><span>=
=C2=A0</span></p>

<p class=3D"MsoNormal" align=3D"center" style=3D"text-align:center">Bitcoin=
=E2=80=99s
verification system, mining, has a dynamic difficulty calculation rate, whi=
ch
means every 2016 blocks or 2 weeks the difficulty changes making mining lit=
tle
bit easy or a bit difficult, but keeping the same maximum output of 1mb per
block, so this means every 2 weeks on 2016mb worth of transactions can get
verified assuming all blocks are filled to the brim, any amount of excess
transactions would not get verified due to lack of space and would get carr=
ied
over to the next cycle, over a period of time this becomes a massive amount=
 and
has led to the current blockchain congestion.</p>

<p class=3D"MsoNormal" align=3D"center" style=3D"text-align:center"><span>=
=C2=A0</span></p>

<p class=3D"MsoNormal" align=3D"center" style=3D"text-align:center">A uniqu=
e solution is
to let the bitcoin network change the maximum block size as per the prevail=
ing
network conditions, this solution borrows some aspects of both the demand a=
nd
supply factor and dynamic change of network difficulty (amount of work done=
 to
verify transactions).</p>

<p class=3D"MsoNormal" align=3D"center" style=3D"text-align:center"><span>=
=C2=A0</span></p>

<p class=3D"MsoNormal" align=3D"center" style=3D"text-align:center">This wo=
uld be
achieved by tracking the volume of the total size of transactions done betw=
een
2 consecutive network difficulty changes and dividing it by 2016, the numbe=
r of
blocks mined between 2 consecutive network difficulty changes. The resultin=
g
answer would be rounded up to the nearest kb and then compared to the previ=
ous
block size, the higher between the two would be taken as the new maximum bl=
ock
size. The extra space would be helpful if a malicious attacker tries to cre=
ate
a lot of small dust transactions and flood the network. Let us take a look =
at
a=C2=A0 example of how it would affect the
bitcoin network in a real life scenario.</p>

<p class=3D"MsoNormal" align=3D"center" style=3D"text-align:center"><span>=
=C2=A0</span></p>

<p class=3D"MsoNormal" align=3D"center" style=3D"text-align:center">Dynamic=
 block size
calculation (B) =3D Total size of transactions from previous network diffic=
ulty
change(ST) / 2016</p>

<p class=3D"MsoNormal" align=3D"center" style=3D"text-align:center">We comp=
are this with
the current block size and the higher is accepted as new block size.</p>

<p class=3D"MsoNormal" align=3D"center" style=3D"text-align:center"><span>=
=C2=A0</span></p>

<p class=3D"MsoNormal" align=3D"center" style=3D"text-align:center">For exa=
mple purposes
the block numbers have been changed for easy understanding.</p>

<p class=3D"MsoNormal" align=3D"center" style=3D"text-align:center">If duri=
ng cycle 1,
block number 1 to block number 2016 the total size of transactions is 1608m=
b,recalculating
it with the dynamic block size algorithm would give the following result:</=
p>

<p class=3D"MsoNormal" align=3D"center" style=3D"text-align:center">Dynamic=
 block size
calculation (B) =3D ST/2016</p>

<p class=3D"MsoNormal" align=3D"center" style=3D"text-align:center">1608/20=
16=3D0.79761905=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 which is 797kb</p>

<p class=3D"MsoNormal" align=3D"center" style=3D"text-align:center">We comp=
are this with
the current block size which is 1mb (current block size in real life) and t=
he
higher of the two becomes the block size for the next cycle.</p>

<p class=3D"MsoNormal" align=3D"center" style=3D"text-align:center">During =
cycle 2, block
number 2017 to block number 4032 the total size of transactions is 2260mb,
recalculating it with the dynamic block size algorithm would give the follo=
wing
result:</p>

<p class=3D"MsoNormal" align=3D"center" style=3D"text-align:center">Dynamic=
 block size calculation
(B) =3D ST/2016</p>

<p class=3D"MsoNormal" align=3D"center" style=3D"text-align:center">2260/20=
16=3D1.12103175=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 which is 1.2mb</p>

<p class=3D"MsoNormal" align=3D"center" style=3D"text-align:center">We comp=
are this with
the current block size which is 1mb and the higher of the two becomes the b=
lock
size for the next cycle, in this case 1.2 mb blocks would be new block size=
.</p>

<p class=3D"MsoNormal" align=3D"center" style=3D"text-align:center"><span>=
=C2=A0</span></p>

<p class=3D"MsoNormal" align=3D"center" style=3D"text-align:center">The abo=
ve examples
can be repeated indefinitely allowing the network to adjust the block size =
automatically.
The dynamic block size is to be calculated at the same time as the network
difficulty is changed.</p>

<p class=3D"MsoNormal" align=3D"center" style=3D"text-align:center">To avoi=
d orphaning of
blocks and very small blocks a minimum block size should also be taken into
effect, the minimum size of the block should be in the range of 30-60% of t=
he
maximum block size; this measure would also stop the propagation of very sm=
all
blocks which aren=E2=80=99t verifying transactions and helping the network =
grow.</p>

<p class=3D"MsoNormal" align=3D"center" style=3D"text-align:center"><span>=
=C2=A0</span></p>

<p class=3D"MsoNormal" align=3D"center" style=3D"text-align:center">THE END=
</p>

<p class=3D"MsoNormal" align=3D"center" style=3D"text-align:center">Any que=
stions ?</p>

<p class=3D"MsoNormal" align=3D"center" style=3D"text-align:center">Mail me=
 at: <span style=3D"color:black"><a href=3D"mailto:contashk18@gmail.com">co=
ntashk18@gmail.com</a><span></span></span></p>

<p class=3D"MsoNormal" align=3D"center" style=3D"text-align:center"><span>=
=C2=A0</span></p></div>

--f403045dd55af6af3a054a858836--