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
|
Return-Path: <psharp.x13@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 1625EB30
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 25 Sep 2017 21:53:33 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yw0-f173.google.com (mail-yw0-f173.google.com
[209.85.161.173])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 61A944AE
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 25 Sep 2017 21:53:32 +0000 (UTC)
Received: by mail-yw0-f173.google.com with SMTP id s62so5780325ywg.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 25 Sep 2017 14:53:32 -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=jFpL7AnoHPggyTfeIF9hXjoFX3iYkpVTsS07JU4GsOI=;
b=YaUyOSCg9sgDVc53h1yBR/NNTyEnwUzKvrFhG6ZK6AXylGuzTPc7kzylpNOUdHLVg/
A0cAUUBZ47WaJcHHy7mYgvEAJdZlL8SBYF2Kj5OJNa0n0XU1MasJqcsb1BXLDoKJYRd/
tMjjZ+v6llhLsnpQilKChxHPE23lXXYCAx0feVxI7DdXrMl/CTmUH0AuyQ3JsRUenFeW
Tu9cDxWwFJ555/XO5n13VqF1jh7/wU35OVZetOQOTqtlhQM1sI2c4Zi0s8BwHZWCj3eB
Sz6Jmvuwz8NV/cLbrNUMHDfpzP4f4NnMuIQNOez5YHwteChE/zKw8+LCyKZ65NvS0Jur
7P9A==
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=jFpL7AnoHPggyTfeIF9hXjoFX3iYkpVTsS07JU4GsOI=;
b=YbWSNchwKJIoPWShWGNPL9bJ9tD56znXXVb0IbQdMIWCwinbXb9G+VeyXNiDdH/Psj
t0oElbMzBKcq4EdOeUqWnpslQoAA/o6MxejaplykQcZReXm8BxtFIcAohOgqKVWd6FIl
AN/xmDAQ3mBEUZCYFJUgFdCYmZwsgmEzyLDV31xPmCzi/KqdxgFXHkvtplStm+bMp+HF
/XainiDj6VNQ610RgJIA8GUQA5I3Ox2g5C8Wq+kF3Q8a1icz2rloDz4quXI6i5xrdu8W
fyX5Pxzy5WYrjzldJgsvOwE3Ax+LuCJ5mJS2q6AxGk4d2UKH84jHMbxNzmZFcCQJroC3
9bbg==
X-Gm-Message-State: AHPjjUgBZ5fuBblZcHigYlyiiyfXVHcR2b8HT/YfhA0WC6jp+/jL36ud
/4sv53eNyMAGWbpi39QRwGgwWxv10HICiIGXWFPWblec
X-Google-Smtp-Source: AOwi7QBRC6fkcQagRBjo0f8S512vpkxJhn1/YKia23uLS/ZW0JKJiovjSk75wrtAhb2KdYMvT/dy3gPIVZh+f7uyHFE=
X-Received: by 10.37.239.82 with SMTP id w18mr5523608ybm.55.1506376411223;
Mon, 25 Sep 2017 14:53:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.45.77 with HTTP; Mon, 25 Sep 2017 14:53:30 -0700 (PDT)
From: Patrick Sharp <psharp.x13@gmail.com>
Date: Mon, 25 Sep 2017 15:53:30 -0600
Message-ID: <CAES+R-q6v=Qc2zZgczNfKhrBtZ0kCt0Um90miAMGB0npp4zAKQ@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary="089e0828d49ce39ce4055a0a9609"
X-Spam-Status: No, score=0.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HTML_MESSAGE,
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: Mon, 25 Sep 2017 22:47:06 +0000
Subject: [bitcoin-dev] idea post: bitcoin side chain implementation
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: Mon, 25 Sep 2017 21:53:33 -0000
--089e0828d49ce39ce4055a0a9609
Content-Type: text/plain; charset="UTF-8"
Hello Devs,
I am Patrick Sharp. I just graduated with a BS is computer science. Forgive
my ignorance.
As per bip-0002 I have scoured each bip available on the wiki to see if
these ideas have already been formally proposed and now as per bip-0002
post these ideas here.
First and foremost I acknowledge that these ideas are not original nor new.
Side Chains:
Bip-R10 offers a mechanism to assign custody or transfer coins from one
chain to another. However I did not find a bip that proposed a formal
bitcoin side chain.
My proposal
- They are officially supported, tracked and built by official bitcoin
software meaning that they are not an external chain
- each chain has an identifier in the block header i.e. main chain: 0,
first chain: 1, second chain: 2...
- the number of chains including the main chain that exists is always a
power of 2, this power will also be included in the block header.
- each address is assigned to a chain via chain = (address) mod (number
of chains)
- to be valid an addresse's next transaction will first send their
coins to their chain if they are not already there
- if the address they are sending to is outside their chain their
transaction will be submitted to both chains and transaction fee will be
split between chains
- They come into being via a fork or split
- every 2016 blocks (upon recalculation of difficulty) if some
percentage (lets say 10%) of blocks on any chain are larger than some
specified amount (lets say 750 KB) then all chains are called to
increment
their power value and fork on their block.
- miner of chain x creates genesis block for chain x+2^previous
power
- upon fork, the difficulty of the old chain and the new chain
will be half the next difficulty
- if every chain has gone 2016 block without surpassing some amount
(lets say 250 KB) at least some percentage of the time (lets say 10%) all
chains will be called to join, decrement their power and double their
difficulty
- given miner of chain x, if x not less than 2^new power, chain
will be marked dead or sleeping
- miners who mine blocks on the chain that was joined (the chain
with the smaller identifier) may have to make a block for the sleeping
chain if transactions include funds that fully or partially
originate from
the sleeping chain
- dead chain are revived on next split.
- each block's reward outside of transaction fees will be the
(current bounty / 2^fork power) except obviously for dead blocks who's
reward is already included in their joined block
- benefits
- dynamically scales to any level of usage, no more issues about
block size
- miners have incentive to keep all difficulties close to parity
- if miners are limited by hard drive space they don't have to mine
every chain (though they should have trusted peers working on
other chains
to verify transactions that originate off their chains, faulty block will
still be unaccepted by the rest of the miners)
- though work will still grow linearly with the number of chains due
to having to hash each separate header, some of the overhead may remain
constant and difficulty and reward will still be balanced.
- transactions are pseudo equally distributed between chains.
- rewards will be more distributed (doesn't' really matter, except
that its beautiful)
- cons
- because most transactions will be double recorded the non-volatile
memory foot print of bitcoin doubles (since miners do not need
all chains i
believe this solution not only overcomes this cost but may decrease the
foot print per miner in the long run overall)
- transactions will hang in limbo until both chains have picked them
up, a forever limboed transaction could result in lost coins, as
long as a
transaction fee has been included this risk should be mitigated.
I believe this idea is applicable to the entire community. I would like
your thoughts and suggestions. I obviously think this is a freaking awesome
idea. I know it is quite ambitious but it is the next step in evolution
that bitcoin needs to take to be a viable competitor to visa.
I come to you to ask if this has any chance of acceptance.
-Patrick
--089e0828d49ce39ce4055a0a9609
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><span style=3D"font-size:12.8px">Hello Devs,</span><div st=
yle=3D"font-size:12.8px"><br></div><div style=3D"font-size:12.8px">I am Pat=
rick Sharp. I just graduated with a BS is computer science. Forgive my igno=
rance.</div><div style=3D"font-size:12.8px"><br></div><div style=3D"font-si=
ze:12.8px">As per bip-0002 I have scoured each bip available on the wiki to=
see if these ideas have already been formally proposed and now as per bip-=
0002 post these ideas here.</div><div style=3D"font-size:12.8px"><br></div>=
<div style=3D"font-size:12.8px">First and foremost I acknowledge that these=
ideas are not original nor new.</div><div style=3D"font-size:12.8px"><br><=
/div><div style=3D"font-size:12.8px">Side Chains:</div><div style=3D"font-s=
ize:12.8px"><br></div><div style=3D"font-size:12.8px">Bip-R10 offers a mech=
anism to assign custody or transfer coins from one chain to another. Howeve=
r I did not find a bip that proposed a formal bitcoin side chain.</div><div=
style=3D"font-size:12.8px"><br></div><div style=3D"font-size:12.8px">My pr=
oposal</div><div style=3D"font-size:12.8px"><ul><li style=3D"margin-left:15=
px">They are officially supported, tracked and built by official bitcoin so=
ftware meaning that they are not an external chain</li><li style=3D"margin-=
left:15px">each chain has an identifier in the block header i.e. main chain=
: 0, first chain: 1, second chain: 2...</li><li style=3D"margin-left:15px">=
the number of chains including the main chain that exists is always a power=
of 2, this power will also be included in the block header.</li><li style=
=3D"margin-left:15px">each address is assigned to a chain via chain =3D (ad=
dress) mod (number of chains)</li><ul><li style=3D"margin-left:15px">to be =
valid an addresse's next transaction will first send their coins to the=
ir chain if they are not already there</li><li style=3D"margin-left:15px">i=
f the address they are sending to is outside their chain their transaction =
will be submitted to both chains and transaction fee will be split between =
chains</li></ul><li style=3D"margin-left:15px">They come into being via a f=
ork or split</li><ul><li style=3D"margin-left:15px">every 2016 blocks (upon=
recalculation of difficulty) if some percentage (lets say 10%) of blocks o=
n any chain are larger than some specified amount (lets say 750 KB) then al=
l chains are called to increment their power value and fork on their block.=
</li><ul><li style=3D"margin-left:15px">miner of chain x creates genesis bl=
ock for chain x+2^previous power</li><li style=3D"margin-left:15px">upon fo=
rk, the difficulty of the old chain and the new chain will be half the next=
difficulty</li></ul><li style=3D"margin-left:15px">if every chain has gone=
2016 block without surpassing some amount (lets say 250 KB) at least some =
percentage of the time (lets say 10%) all chains will be called to join, de=
crement their power and double their difficulty</li><ul><li style=3D"margin=
-left:15px">given miner of chain x, if x not less than 2^new power, chain w=
ill be marked dead or sleeping</li><li style=3D"margin-left:15px">miners wh=
o mine blocks on the chain that was joined (the chain with the smaller iden=
tifier) may have to make a block for the sleeping chain if transactions inc=
lude funds that fully or partially originate from the sleeping chain</li><l=
i style=3D"margin-left:15px">dead chain are revived on next split.</li></ul=
><li style=3D"margin-left:15px">each block's reward outside of transact=
ion fees will be the (current bounty / 2^fork power) except obviously=C2=A0=
for dead blocks who's reward is already included in their joined block<=
/li></ul><li style=3D"margin-left:15px">benefits</li><ul><li style=3D"margi=
n-left:15px">dynamically scales to any level of usage, no more issues about=
block size</li><li style=3D"margin-left:15px">miners have incentive to kee=
p all difficulties close to parity</li><li style=3D"margin-left:15px">if mi=
ners are limited by hard drive space they don't have to mine every chai=
n (though they should have trusted peers working on other chains to verify =
transactions that originate off their chains, faulty block will still be un=
accepted by the rest of the miners)</li><li style=3D"margin-left:15px">thou=
gh work will still grow linearly with the number of chains due to having to=
hash each separate header, some of the overhead may remain constant and di=
fficulty and reward will still be balanced.</li><li style=3D"margin-left:15=
px">transactions are pseudo equally distributed between chains.</li><li sty=
le=3D"margin-left:15px">rewards will be more distributed (doesn't' =
really matter, except that its beautiful)</li></ul><li style=3D"margin-left=
:15px">cons</li><ul><li style=3D"margin-left:15px">because most transaction=
s will be double recorded the non-volatile memory foot print of bitcoin dou=
bles (since miners do not need all chains i believe this solution not only =
overcomes this cost but may decrease the foot print per miner in the long r=
un overall)</li><li style=3D"margin-left:15px">transactions will hang in li=
mbo until both chains have picked them up, a forever limboed transaction co=
uld result in lost coins, as long as a transaction fee has been included th=
is risk should be mitigated.</li></ul></ul><div>I believe this idea is appl=
icable to the entire community. I would like your thoughts and suggestions.=
I obviously think this is a freaking awesome idea. I know it is quite ambi=
tious but it is the next step in evolution that bitcoin needs to take to be=
a viable competitor to visa.</div><div><br></div><div>I come to you to ask=
if this has any chance of acceptance.</div></div><div style=3D"font-size:1=
2.8px"><br></div><div style=3D"font-size:12.8px">-Patrick</div></div>
--089e0828d49ce39ce4055a0a9609--
|
