summaryrefslogtreecommitdiff
path: root/c4/051ded0763d46b62273ee63898c37c0cce224e
blob: 66c4bac49e9313560f88de65cfdf4a86d26eb192 (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
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
Return-Path: <max.jacob.hastings@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 6FE2C361C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 30 Oct 2018 04:41:09 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-it1-f181.google.com (mail-it1-f181.google.com
	[209.85.166.181])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3309EA7
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 30 Oct 2018 04:41:08 +0000 (UTC)
Received: by mail-it1-f181.google.com with SMTP id r5-v6so10311002ith.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 29 Oct 2018 21:41:08 -0700 (PDT)
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=AJxjpaEvhb5+PT+LVLrSCZwf1Q0d7e8kJQ38MuzIqHw=;
	b=mKuCj+UVzlrxaWb3WQBf1BOpMRo/+ojklhp4psAbdBTJRJJfZNL5LPiKl7VZWonnYo
	DvPaBrZcdIkBZnNVI+1+OUIOBpkDVF0e5edDD/cztfEQ8csiuR/IV/pqHuNEtbCbk/17
	CT8dW3LBB7jJanIdH2Z+oPyMWfskDC01Y45bUC0eltsuTYAqsRr0lmC8fh8ZxmFDifLS
	k+GwV9TBOM2bNvcKWy9T0TqwJboQ6LR9oAoVEzjCKFOd0k4kETc1ZPoLeECMJbz+GKCi
	6h8/HNWeNeed52mgSt53raL2jvIymGEWaamgYMfeNNAaiEDXcvj70NLN6Be/qG3BIpRG
	Z0kw==
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=AJxjpaEvhb5+PT+LVLrSCZwf1Q0d7e8kJQ38MuzIqHw=;
	b=N6sqtMp71QFyCqiRhnrw20AJdy3m8mLokx/AE/oIySaWAOOR0/5PLkGjY5fJEHqzYG
	mOrBkekamVVI69jdaIUTMMDegNWWWS8w93v9oPXw02lXVXg6gmtlWCajN+/Hgbrx9O9X
	b/K5/IUHQVPc5ddACtv1kLCBS+XjdLZXyxOEyCLM4HLwAburPfKg2IdRqM6RCunIjMPz
	CZap/XS/+1NI31V5bCP/R79firInAc3OEm8D6Dc+bSSYRSzBoGMiDVUtRK01Ly5CASL6
	nqlCv2fEeOrwfXnkEYGb8XkfkeK135HdcPqKPxkhGWOczBq2IGh1ggnc36sTXFjjZB5d
	V8tw==
X-Gm-Message-State: AGRZ1gJRYjKOGrelPSELrMT+LDLjlZHDKKHsytZEE/4ug923bGf41p0p
	vWkv+EfqvswJkLoEMQ47N8IUnkDz00gZSYAPmSFAp7x9
X-Google-Smtp-Source: AJdET5eMUkQ27ZhJktYR9Yr/YLqBLTvH3Vt8bc3guJirewz595X4USC4kKgCAq0a0BjGC7y76ihyZa35RdG54tQ7+m8=
X-Received: by 2002:a24:9886:: with SMTP id n128-v6mr406173itd.7.1540874467113;
	Mon, 29 Oct 2018 21:41:07 -0700 (PDT)
MIME-Version: 1.0
From: Max Hastings <max.jacob.hastings@gmail.com>
Date: Mon, 29 Oct 2018 23:40:54 -0500
Message-ID: <CABPqyW=jOJo3edbvUUNRF2_5-vQSZ5AChPQ7TafWd5Mzv2MBWw@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary="0000000000004181a405796acb68"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Wed, 31 Oct 2018 04:44:23 +0000
Subject: [bitcoin-dev] Proposal to modify POW protocol to improve network
	decentralization.
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: Tue, 30 Oct 2018 04:41:09 -0000

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

I wrote up a proposal that modifies the proof of work protocol to improve
decentralization, by encouraging miners to move from larger pools to
smaller pools or even mining solo, while still receiving a regular stream
of income.

You can read my proposal here:
https://drive.google.com/open?id=3D1vkk7yI7F2QGDIBhHf_aYVHzpWrcaPVZA

I am looking for feedback on the idea.

Thanks,
Max

---------------------------------------------------------------------------=
-------

Mining Share Transactions

Max Hastings



*Abstract*=E2=80=94One of the challenges Bitcoin continues to face is the t=
endency
of the network becoming more centralized over time as miners join pools
rather than mining solo. As of this writing the four biggest pools control
over 51% of the total networking hash power, with the largest of the four
controlling almost 20%. This paper will discuss a possible modification to
the current Proof of Work protocol that Bitcoin and other cryptocurrencies
use that will help incentivize miners to mine solo or join a smaller pool,
rather than joining the largest pools.



*1.      **What is Pool Mining?*

Under the proof of work protocol miners compete with one another to mine
the next block by hashing a block header, then making small changes to the
nonce or timestamp to get a different hash value each time the data is
hashed. Miners will do this until the resulting hash value is below the
current difficulty target. At that point the miner has successfully solved
a block, which then is propagated across the network and validated by each
node. This proof of work system works as a lottery that a miner can win for
every block. In Bitcoin=E2=80=99s case a new block is found on average ever=
y 10
minutes. Currently there=E2=80=99s an estimated number of 100,000 miners on=
 the
Bitcoin network with a combined hash power of 50 million TH/s. With that
many participants with that much hash power, the average time it takes for
a miner to solve a block by themselves can take a long time. Most miners
demand a more consistent stream of income rather than waiting to win the
lottery. They currently achieve this in one of two ways, centralized pool
mining and p2pool mining. Centralized pool mining works by a pool operator
hosting a full node, generating a block header for the next block and
distributing the block header to their pool miners to start hashing. The
miners on the pool will occasionally submit what is known as =E2=80=9Cshare=
s=E2=80=9D which
is a hash that solves a lower difficulty than what the block needs to be
solved, back to the pool operator. The purpose of this is to prove to the
pool operator that you are completing work. Every so often a miner on the
pool will solve a share that also solves the block which the pool operator
will then propagate across the network. The pool operator will then
distribute the block reward to all miners based on the number of shares
they have contributed.

*2.       **How Pool Mining centralizes the Blockchain*

When a miner joins a pool they mine the block header that is given to them
by the pool operator. The pool operator has full control over which
transactions will go inside the block. This gives the pool operator the
ability to maliciously use the entire hashing power of the pool to attempt
a double spend attack on the network, if desired. The largest Bitcoin
mining pool has 20% of the total network hashing power. This is not enough
power to even attempt a double spend attack, however if multiple large
pools conspire they could easily conduct a double spend attack on the
network. It doesn=E2=80=99t take more than a few bad pool operators to coll=
ude with
one another to conduct a harmful double spend attack on the network.

*3.      **Mining Share Transactions*

Mining share transactions help incentivize miners to mine solo instead of
joining a pool while still retaining the same benefits of receiving a
continuous stream of small rewards rather than having to mine an entire
block. Mining shares also significantly change how consensus happens on the
blockchain. To mine the next block, miners first create mining share
transactions which represent the work of having mined a fraction of the
next block. Each block is required to contain X number of mining share
transactions for it to be considered valid. This is the reason why all
nodes on the network start mining the next block by first mining share
transactions. Each mining share transaction contains two crucial pieces of
data. The hash of the previous block, and a transaction output. After a
node receives or creates X amount of mining share transactions for the next
block, the nodes will begin to hash a block header which will contain X
amount of mining share transactions in addition to the normal transactions.
Keep in mind, the target difficulty for generating a valid block header and
a mining share are equal.

*4.      **Maintaining a Blockchain Consensus*

A block header contains the Merkle root which contains the transactions
that are in a block. Traditionally the block header is backed by 100% of
the mining work by the network, but with mining shares the block header is
only backed by a fraction of the total work, precisely 1 / (X + 1). Where X
is the total number of mining share transactions required in each block. It
will be common to have multiple competing block headers broadcasted shortly
after X amount of mining share transactions have been mined. However, after
a node receives a valid block, it will begin mining new share transactions
on to that chain. If multiple valid blocks are received by the node, they
will have to pick which fork to mine off of. As mining share transactions
are broadcasted throughout the network, nodes will mine off the fork that
has the best chance at reaching X amount of mining share transactions first
so that the next block can be mined. For example, block A, and block B are
both valid blocks which creates a fork on the chain. As nodes start
generating mining shares for either fork they will be continuously
monitoring the competing forks for how many mining shares they currently
have. Nodes will switch to the fork with the most work behind it based on
the number of mining share transactions already mined. This will allow the
blockchain network to reach a consensus fairly quickly as nodes monitor the
number of mining share transactions coming in for multiple competing blocks=
.

*5.      **How to measure Transaction Confirmations.*

Traditionally the confirmation number for transactions are calculated based
on the depth that the transaction is in the chain. For example, if the
transaction is in the block at height 10, and the current block height is
15, then the number of confirmations for that transaction is 6. With mining
share transactions, confirmations are measured differently since the block
only represents a fraction of the total work. For example, if X is 99,
meaning each block needs 99 mining share transactions to be considered
valid, then each block and mining share transaction is equal to 0.01
confirmations. If Transaction A is in block 1, and there are currently 49
mining share transactions mined for block 2 then transaction A has a
confirmation number of 0.5. If block 2 is already mined and there are 49
mining shares for block 3, then transaction A would have a confirmation
number of 1.5.

*6.      **Conclusion*

One of the unique attributes of Bitcoin is that it is a decentralized
digital currency. It is important to keep Bitcoin and other cryptocurrency
networks as decentralized as possible to prevent bad actors from performing
a double spend attack on the network. With mining share transactions, users
are encouraged to mine solo rather than mining on a pool while still
retaining a predictable stream of income. With a more decentralized
network, it makes it more difficult for bad actors to attack the network.
Mining share transactions modifies the proof of work protocol in a way that
changes how blockchain consensus happens. Nodes monitor the number of share
transactions for competing blocks and contribute to the fork that has the
most. This allows for consensus to happen fairly quickly after competing
blocks are broadcasted. Confirmations also have to be measured differently
so that users receiving transactions can accurately figure out how
confident they should be that their transaction is final. Mining share
transactions will increase the security and the integrity of the blockchain
network by making it more decentralized.

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

<div dir=3D"ltr"><div>I wrote up a proposal that modifies the proof of work=
 protocol to improve decentralization, by encouraging=C2=A0miners to move f=
rom larger pools to smaller pools or even mining solo, while still receivin=
g a regular stream of income.<br><br>You can read my proposal here:<br><a h=
ref=3D"https://drive.google.com/open?id=3D1vkk7yI7F2QGDIBhHf_aYVHzpWrcaPVZA=
" target=3D"_blank">https://drive.google.com/open?id=3D1vkk7yI7F2QGDIBhHf_a=
YVHzpWrcaPVZA</a></div><div><br></div><div>I am looking for feedback on the=
 idea.</div><div><br></div><div>Thanks,</div><div>Max</div><div><br></div><=
div>-----------------------------------------------------------------------=
-----------</div><div><br></div><div><p class=3D"MsoNormal" align=3D"center=
" style=3D"text-align:center;margin:0in 0in 8pt;line-height:107%;font-size:=
11pt;font-family:Calibri,sans-serif"><span style=3D"font-size:20pt;line-hei=
ght:107%;font-family:&quot;Times New Roman&quot;,serif">Mining
Share Transactions</span></p>

<p class=3D"MsoNormal" align=3D"center" style=3D"text-align:center;margin:0=
in 0in 8pt;line-height:107%;font-size:11pt;font-family:Calibri,sans-serif">=
<span style=3D"font-family:&quot;Times New Roman&quot;,serif">Max Hastings<=
/span></p>

<p class=3D"MsoNormal" align=3D"center" style=3D"text-align:center;margin:0=
in 0in 8pt;line-height:107%;font-size:11pt;font-family:Calibri,sans-serif">=
<span style=3D"font-family:&quot;Times New Roman&quot;,serif">=C2=A0</span>=
</p>

<p class=3D"MsoNormal" style=3D"margin:0in 0.5in 8pt;line-height:107%;font-=
size:11pt;font-family:Calibri,sans-serif"><b><span style=3D"line-height:107=
%;font-family:&quot;Times New Roman&quot;,serif">Abstract</span></b><span s=
tyle=3D"line-height:107%;font-family:&quot;Times New Roman&quot;,serif">=E2=
=80=94One
of the challenges Bitcoin continues to face is the tendency of the network
becoming more centralized over time as miners join pools rather than mining
solo. As of this writing the four biggest pools control over 51% of the tot=
al
networking hash power, with the largest of the four controlling almost 20%.
This paper will discuss a possible modification to the current Proof of Wor=
k
protocol that Bitcoin and other cryptocurrencies use that will help incenti=
vize
miners to mine solo or join a smaller pool, rather than joining the largest
pools.</span></p>

<p class=3D"MsoNormal" style=3D"margin:0in 0.5in 8pt;line-height:107%;font-=
size:11pt;font-family:Calibri,sans-serif"><span style=3D"line-height:107%;f=
ont-family:&quot;Times New Roman&quot;,serif">=C2=A0</span></p>

<p class=3D"gmail-MsoListParagraph" style=3D"margin:0in 0in 8pt 0.25in;line=
-height:107%;font-size:11pt;font-family:Calibri,sans-serif"><b><span style=
=3D"font-size:12pt;line-height:107%;font-family:&quot;Times New Roman&quot;=
,serif">1.<span style=3D"font-variant-numeric:normal;font-variant-east-asia=
n:normal;font-weight:normal;font-stretch:normal;font-size:7pt;line-height:n=
ormal;font-family:&quot;Times New Roman&quot;">=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0
</span></span></b><b><span style=3D"font-size:12pt;line-height:107%;font-fa=
mily:&quot;Times New Roman&quot;,serif">What is Pool Mining?</span></b></p>

<p class=3D"gmail-MsoListParagraph" style=3D"margin:0in 0in 8pt;line-height=
:107%;font-size:11pt;font-family:Calibri,sans-serif"><span style=3D"line-he=
ight:107%;font-family:&quot;Times New Roman&quot;,serif">Under the proof of
work protocol miners compete with one another to mine the next block by has=
hing
a block header, then making small changes to the nonce or timestamp to get =
a
different hash value each time the data is hashed. Miners will do this unti=
l
the resulting hash value is below the current difficulty target. At that po=
int
the miner has successfully solved a block, which then is propagated across =
the
network and validated by each node. This proof of work system works as a
lottery that a miner can win for every block. In Bitcoin=E2=80=99s case a n=
ew block is
found on average every 10 minutes. Currently there=E2=80=99s an estimated n=
umber of
100,000 miners on the Bitcoin network with a combined hash power of 50 mill=
ion
TH/s. With that many participants with that much hash power, the average ti=
me
it takes for a miner to solve a block by themselves can take a long time. M=
ost
miners demand a more consistent stream of income rather than waiting to win=
 the
lottery. They currently achieve this in one of two ways, centralized pool
mining and p2pool mining. Centralized pool mining works by a pool operator
hosting a full node, generating a block header for the next block and
distributing the block header to their pool miners to start hashing. The mi=
ners
on the pool will occasionally submit what is known as =E2=80=9Cshares=E2=80=
=9D which is a hash
that solves a lower difficulty than what the block needs to be solved, back=
 to
the pool operator. The purpose of this is to prove to the pool operator tha=
t
you are completing work. Every so often a miner on the pool will solve a sh=
are
that also solves the block which the pool operator will then propagate acro=
ss
the network. The pool operator will then distribute the block reward to all
miners based on the number of shares they have contributed.</span></p>

<p class=3D"gmail-MsoListParagraph" style=3D"margin:0in 0in 8pt 0.25in;line=
-height:107%;font-size:11pt;font-family:Calibri,sans-serif"><b><span style=
=3D"line-height:107%;font-family:&quot;Times New Roman&quot;,serif">2.<span=
 style=3D"font-variant-numeric:normal;font-variant-east-asian:normal;font-w=
eight:normal;font-stretch:normal;font-size:7pt;line-height:normal;font-fami=
ly:&quot;Times New Roman&quot;">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
</span></span></b><b><span style=3D"font-size:12pt;line-height:107%;font-fa=
mily:&quot;Times New Roman&quot;,serif">How Pool Mining centralizes the Blo=
ckchain</span></b><span style=3D"line-height:107%;font-family:&quot;Times N=
ew Roman&quot;,serif"></span></p>

<p class=3D"MsoNormal" style=3D"margin:0in 0in 8pt;line-height:107%;font-si=
ze:11pt;font-family:Calibri,sans-serif"><span style=3D"line-height:107%;fon=
t-family:&quot;Times New Roman&quot;,serif">When a miner joins a pool they =
mine the
block header that is given to them by the pool operator. The pool operator =
has
full control over which transactions will go inside the block. This gives t=
he
pool operator the ability to maliciously use the entire hashing power of th=
e
pool to attempt a double spend attack on the network, if desired. The large=
st
Bitcoin mining pool has 20% of the total network hashing power. This is not
enough power to even attempt a double spend attack, however if multiple lar=
ge
pools conspire they could easily conduct a double spend attack on the netwo=
rk. It
doesn=E2=80=99t take more than a few bad pool operators to collude with one=
 another to
conduct a harmful double spend attack on the network.</span></p>

<p class=3D"gmail-MsoListParagraph" style=3D"margin:0in 0in 6pt 0.25in;line=
-height:107%;font-size:11pt;font-family:Calibri,sans-serif"><b><span style=
=3D"font-size:12pt;line-height:107%;font-family:&quot;Times New Roman&quot;=
,serif">3.<span style=3D"font-variant-numeric:normal;font-variant-east-asia=
n:normal;font-weight:normal;font-stretch:normal;font-size:7pt;line-height:n=
ormal;font-family:&quot;Times New Roman&quot;">=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0
</span></span></b><b><span style=3D"font-size:12pt;line-height:107%;font-fa=
mily:&quot;Times New Roman&quot;,serif">Mining Share Transactions</span></b=
></p>

<p class=3D"MsoNormal" style=3D"margin:0in 0in 8pt;line-height:107%;font-si=
ze:11pt;font-family:Calibri,sans-serif"><span style=3D"line-height:107%;fon=
t-family:&quot;Times New Roman&quot;,serif">Mining share transactions help =
incentivize
miners to mine solo instead of joining a pool while still retaining the sam=
e
benefits of receiving a continuous stream of small rewards rather than havi=
ng
to mine an entire block. Mining shares also significantly change how consen=
sus
happens on the blockchain. To mine the next block, miners first create mini=
ng
share transactions which represent the work of having mined a fraction of t=
he
next block. Each block is required to contain X number of mining share
transactions for it to be considered valid. This is the reason why all node=
s on
the network start mining the next block by first mining share transactions.=
 Each
mining share transaction contains two crucial pieces of data. The hash of t=
he
previous block, and a transaction output. After a node receives or creates =
X
amount of mining share transactions for the next block, the nodes will begi=
n to
hash a block header which will contain X amount of mining share transaction=
s in
addition to the normal transactions. Keep in mind, the target difficulty fo=
r generating
a valid block header and a mining share are equal.</span></p>

<p class=3D"gmail-MsoListParagraph" style=3D"margin:0in 0in 8pt 0.25in;line=
-height:107%;font-size:11pt;font-family:Calibri,sans-serif"><b><span style=
=3D"font-size:12pt;line-height:107%;font-family:&quot;Times New Roman&quot;=
,serif">4.<span style=3D"font-variant-numeric:normal;font-variant-east-asia=
n:normal;font-weight:normal;font-stretch:normal;font-size:7pt;line-height:n=
ormal;font-family:&quot;Times New Roman&quot;">=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0
</span></span></b><b><span style=3D"font-size:12pt;line-height:107%;font-fa=
mily:&quot;Times New Roman&quot;,serif">Maintaining a Blockchain Consensus<=
/span></b></p>

<p class=3D"MsoNormal" style=3D"margin:0in 0in 8pt;line-height:107%;font-si=
ze:11pt;font-family:Calibri,sans-serif"><span style=3D"line-height:107%;fon=
t-family:&quot;Times New Roman&quot;,serif">A block header contains the Mer=
kle root
which contains the transactions that are in a block. Traditionally the bloc=
k
header is backed by 100% of the mining work by the network, but with mining
shares the block header is only backed by a fraction of the total work,
precisely 1 / (X + 1). Where X is the total number of mining share transact=
ions
required in each block. It will be common to have multiple competing block
headers broadcasted shortly after X amount of mining share transactions hav=
e
been mined. However, after a node receives a valid block, it will begin min=
ing
new share transactions on to that chain. If multiple valid blocks are recei=
ved
by the node, they will have to pick which fork to mine off of. As mining sh=
are
transactions are broadcasted throughout the network, nodes will mine off th=
e
fork that has the best chance at reaching X amount of mining share transact=
ions
first so that the next block can be mined. For example, block A, and block =
B
are both valid blocks which creates a fork on the chain. As nodes start
generating mining shares for either fork they will be continuously monitori=
ng
the competing forks for how many mining shares they currently have. Nodes w=
ill
switch to the fork with the most work behind it based on the number of mini=
ng
share transactions already mined. This will allow the blockchain network to
reach a consensus fairly quickly as nodes monitor the number of mining shar=
e
transactions coming in for multiple competing blocks.</span></p>

<p class=3D"gmail-MsoListParagraph" style=3D"margin:0in 0in 8pt 0.25in;line=
-height:107%;font-size:11pt;font-family:Calibri,sans-serif"><b><span style=
=3D"font-size:12pt;line-height:107%;font-family:&quot;Times New Roman&quot;=
,serif">5.<span style=3D"font-variant-numeric:normal;font-variant-east-asia=
n:normal;font-weight:normal;font-stretch:normal;font-size:7pt;line-height:n=
ormal;font-family:&quot;Times New Roman&quot;">=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0
</span></span></b><b><span style=3D"font-size:12pt;line-height:107%;font-fa=
mily:&quot;Times New Roman&quot;,serif">How to measure Transaction Confirma=
tions.</span></b></p>

<p class=3D"MsoNormal" style=3D"margin:0in 0in 8pt;line-height:107%;font-si=
ze:11pt;font-family:Calibri,sans-serif"><span style=3D"line-height:107%;fon=
t-family:&quot;Times New Roman&quot;,serif">Traditionally the confirmation =
number for
transactions are calculated based on the depth that the transaction is in t=
he
chain. For example, if the transaction is in the block at height 10, and th=
e
current block height is 15, then the number of confirmations for that trans=
action
is 6. With mining share transactions, confirmations are measured differentl=
y
since the block only represents a fraction of the total work. For example, =
if X
is 99, meaning each block needs 99 mining share transactions to be consider=
ed valid,
then each block and mining share transaction is equal to 0.01 confirmations=
. If
Transaction A is in block 1, and there are currently 49 mining share
transactions mined for block 2 then transaction A has a confirmation number=
 of
0.5. If block 2 is already mined and there are 49 mining shares for block 3=
,
then transaction A would have a confirmation number of 1.5.</span></p>

<p class=3D"gmail-MsoListParagraph" style=3D"margin:0in 0in 8pt 0.25in;line=
-height:107%;font-size:11pt;font-family:Calibri,sans-serif"><b><span style=
=3D"font-size:12pt;line-height:107%;font-family:&quot;Times New Roman&quot;=
,serif">6.<span style=3D"font-variant-numeric:normal;font-variant-east-asia=
n:normal;font-weight:normal;font-stretch:normal;font-size:7pt;line-height:n=
ormal;font-family:&quot;Times New Roman&quot;">=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0
</span></span></b><b><span style=3D"font-size:12pt;line-height:107%;font-fa=
mily:&quot;Times New Roman&quot;,serif">Conclusion</span></b></p>

<p class=3D"MsoNormal" style=3D"margin:0in 0in 8pt;line-height:107%;font-si=
ze:11pt;font-family:Calibri,sans-serif"><span style=3D"line-height:107%;fon=
t-family:&quot;Times New Roman&quot;,serif">One of the unique attributes of=
 Bitcoin is
that it is a decentralized digital currency. It is important to keep Bitcoi=
n
and other cryptocurrency networks as decentralized as possible to prevent b=
ad
actors from performing a double spend attack on the network. With mining sh=
are
transactions, users are encouraged to mine solo rather than mining on a poo=
l
while still retaining a predictable stream of income. With a more decentral=
ized
network, it makes it more difficult for bad actors to attack the network.
Mining share transactions modifies the proof of work protocol in a way that=
 changes
how blockchain consensus happens. Nodes monitor the number of share
transactions for competing blocks and contribute to the fork that has the m=
ost.
This allows for consensus to happen fairly quickly after competing blocks a=
re
broadcasted. Confirmations also have to be measured differently so that use=
rs
receiving transactions can accurately figure out how confident they should =
be
that their transaction is final. Mining share transactions will increase th=
e
security and the integrity of the blockchain network by making it more
decentralized.</span></p></div></div>

--0000000000004181a405796acb68--