summaryrefslogtreecommitdiff
path: root/db/db1f4b870a1db5e573e9bcaa01529a4e0fc654
blob: 5e3455f7aeb27544ba36bc6632f4106fdcbf14d2 (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
Return-Path: <johndhuk@live.co.uk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id B5F7E256
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 11 Oct 2016 21:23:48 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from DUB004-OMC4S4.hotmail.com (dub004-omc4s4.hotmail.com
	[157.55.2.79])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 50DAF79
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 11 Oct 2016 21:23:46 +0000 (UTC)
Received: from DUB118-W40 ([157.55.2.71]) by DUB004-OMC4S4.hotmail.com over
	TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); 
	Tue, 11 Oct 2016 14:23:44 -0700
X-TMN: [ppG/TWH8yrsp85ZXgVf7m8k6ncK59WHR]
X-Originating-Email: [johndhuk@live.co.uk]
Message-ID: <DUB118-W404335B158A3BE61A6D164EFDA0@phx.gbl>
Content-Type: multipart/alternative;
	boundary="_d2d1fb10-3faa-4fa4-9dbb-e645565bc877_"
From: John Hardy <john@seebitcoin.com>
Sender: <johndhuk@live.co.uk>
To: "bitcoin-dev@lists.linuxfoundation.org"
	<bitcoin-dev@lists.linuxfoundation.org>
Date: Tue, 11 Oct 2016 21:23:44 +0000
Importance: Normal
In-Reply-To: <DUB118-W3025C67626835237E907A9EFC20@phx.gbl>
References: <DUB118-W3025C67626835237E907A9EFC20@phx.gbl>
MIME-Version: 1.0
X-OriginalArrivalTime: 11 Oct 2016 21:23:44.0581 (UTC)
	FILETIME=[BF0B9750:01D22405]
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE,
	RCVD_IN_DNSWL_LOW 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: Tue, 11 Oct 2016 23:33:46 +0000
Subject: [bitcoin-dev] Could a sidechain protocol create an addressable
 "Internet of Blockchains" and facilitate scaling?
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, 11 Oct 2016 21:23:48 -0000

--_d2d1fb10-3faa-4fa4-9dbb-e645565bc877_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



Sidechains seem an inevitable tool for scaling. They allow Bitcoins to be t=
ransferred from the main blockchain into external blockchains=2C of which t=
here can be any number with radically different approaches.
In current thinking I have encountered=2C sidechains are isolated from each=
 other. To move Bitcoin between them would involve a slow transfer back to =
the mainchain=2C and then out again to a different sidechain.
Could we instead create a protocol for addressable blockchains=2C all using=
 a shared proof of work=2C which effectively acts as an Internet of Blockch=
ains?
Instead of transferring Bitcoin into individual sidechains=2C you move them=
 into the master sidechain=2C which I'll call Angel. The Angel blockchain s=
its at the top of of a tree of blockchains=2C each of which can have radica=
lly different properties=2C but are all able to transfer Bitcoin and data b=
etween each other using a standardised protocol.
Each blockchain has its own address=2C much like an IP address. The Angel b=
lockchain acts as a registrar=2C a public record of every blockchain and it=
s properties. Creating a blockchain is as simple as getting a createBlockch=
ain transaction included in an Angel block=2C with details of parameters su=
ch as block creation time=2C block size limit=2C etc. A decentralised DNS o=
f sorts.
Mining in Angel uses a standardised format=2C creating hashes which allow a=
ll different blockchains to contribute to the same Angel proof of work. Min=
ers must hash the address of the blockchain they are mining=2C and if they =
mine a hash of sufficient difficulty for that blockchain they are able to c=
reate a block.
Blockchains can have child blockchains=2C so a child of Angel might have th=
e address aa9=2C and a child of aa9 might have the address aa9:e4d. The low=
er down the tree you go=2C the lower the security=2C but the lower the tran=
saction fees. If a miner on a lower level produces a hash of sufficient dif=
ficulty=2C they can use it on any parents=2C up to and including the Angel =
blockchain=2C and claim fees on each.
Children always synchronise and follow all parents (and their reorganisatio=
ns)=2C and parents are aware of their children. This allows you to do some =
pretty cool things with security. If a child tries to withdraw to a parent =
after spending on the child (a double spend attempt) this will be visible i=
nstantly=2C and all child nodes will immediately be able to broadcast proof=
 of the double spend to parent chain nodes so they do not mine on those blo=
cks. This effectively means children can inherit a level of security from t=
heir parents without the same PoW difficulty.
There are so many conflicting visions for how to scale Bitcoin. Angel allow=
s the free market to decide which approaches are successful=2C and for comp=
lementary blockchains with different use cases=2C such as privacy=2C high t=
ransaction volume=2C and Turing completeness to more seamlessly exist along=
side each other=2C using Bitcoin as the standard medium of exchange.
I wrote this as a TLDR summary for a (still evolving) idea I had on the bes=
t approach to scale Bitcoin infinitely. I've written more of my thoughts on=
 the idea at https://seebitcoin.com/2016/09/introducing-buzz-a-turing-compl=
ete-concept-for-scaling-bitcoin-to-infinity-and-beyond/
Does anybody think this would be a better=2C more efficient way of implemen=
ting sidechains? It allows infinite scaling=2C and standardisation allows b=
etter pooling of resources.
Thanks=2C
John Hardyjohn@seebitcoin.com 		 	   		   		 	   		  =

--_d2d1fb10-3faa-4fa4-9dbb-e645565bc877_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style><!--
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 12pt=3B
font-family:Calibri
}
--></style></head>
<body class=3D'hmmessage'><div dir=3D'ltr'><br><br><div><hr id=3D"stopSpell=
ing"><div dir=3D"ltr"><div style=3D"color:rgb(34=2C 34=2C 34)=3Bfont-family=
:arial=2C sans-serif=3Bfont-size:small=3B">Sidechains seem an inevitable to=
ol for scaling. They allow Bitcoins to be transferred from the main blockch=
ain into external blockchains=2C of which there can be any number with radi=
cally different approaches.</div><div style=3D"color:rgb(34=2C 34=2C 34)=3B=
font-family:arial=2C sans-serif=3Bfont-size:small=3B"><br></div><div style=
=3D"color:rgb(34=2C 34=2C 34)=3Bfont-family:arial=2C sans-serif=3Bfont-size=
:small=3B">In current thinking I have encountered=2C sidechains are isolate=
d from each other. To move Bitcoin between them would involve a slow transf=
er back to the mainchain=2C and then out again to a different sidechain.</d=
iv><div style=3D"color:rgb(34=2C 34=2C 34)=3Bfont-family:arial=2C sans-seri=
f=3Bfont-size:small=3B"><br></div><div style=3D"color:rgb(34=2C 34=2C 34)=
=3Bfont-family:arial=2C sans-serif=3Bfont-size:small=3B">Could we instead c=
reate a protocol for addressable blockchains=2C all using a shared proof of=
 work=2C which effectively acts as an Internet of Blockchains?</div><div st=
yle=3D"color:rgb(34=2C 34=2C 34)=3Bfont-family:arial=2C sans-serif=3Bfont-s=
ize:small=3B"><br></div><div style=3D"color:rgb(34=2C 34=2C 34)=3Bfont-fami=
ly:arial=2C sans-serif=3Bfont-size:small=3B">Instead of transferring Bitcoi=
n into individual sidechains=2C you move them into the master sidechain=2C =
which I'll call Angel. The Angel blockchain sits at the top of of a tree of=
 blockchains=2C each of which can have radically different properties=2C bu=
t are all able to transfer Bitcoin and data between each other using a stan=
dardised protocol.</div><div style=3D"color:rgb(34=2C 34=2C 34)=3Bfont-fami=
ly:arial=2C sans-serif=3Bfont-size:small=3B"><br></div><div style=3D"color:=
rgb(34=2C 34=2C 34)=3Bfont-family:arial=2C sans-serif=3Bfont-size:small=3B"=
>Each blockchain has its own address=2C much like an IP address. The Angel =
blockchain acts as a registrar=2C a public record of every blockchain and i=
ts properties. Creating a blockchain is as simple as getting a createBlockc=
hain transaction included in an Angel block=2C with details of parameters s=
uch as block creation time=2C block size limit=2C etc. A decentralised DNS =
of sorts.</div><div style=3D"color:rgb(34=2C 34=2C 34)=3Bfont-family:arial=
=2C sans-serif=3Bfont-size:small=3B"><br></div><div style=3D"color:rgb(34=
=2C 34=2C 34)=3Bfont-family:arial=2C sans-serif=3Bfont-size:small=3B">Minin=
g in Angel uses a standardised format=2C creating hashes which allow all di=
fferent blockchains to contribute to the same Angel proof of work. Miners m=
ust hash the address of the blockchain they are mining=2C and if they mine =
a hash of sufficient difficulty for that blockchain they are able to create=
 a block.</div><div style=3D"color:rgb(34=2C 34=2C 34)=3Bfont-family:arial=
=2C sans-serif=3Bfont-size:small=3B"><br></div><div style=3D"color:rgb(34=
=2C 34=2C 34)=3Bfont-family:arial=2C sans-serif=3Bfont-size:small=3B">Block=
chains can have child blockchains=2C so a child of Angel might have the add=
ress aa9=2C and a child of aa9 might have the address aa9:e4d. The lower do=
wn the tree you go=2C the lower the security=2C but the lower the transacti=
on fees. If a miner on a lower level produces a hash of sufficient difficul=
ty=2C they can use it on any parents=2C up to and including the Angel block=
chain=2C and claim fees on each.</div><div style=3D"color:rgb(34=2C 34=2C 3=
4)=3Bfont-family:arial=2C sans-serif=3Bfont-size:small=3B"><br></div><div s=
tyle=3D"color:rgb(34=2C 34=2C 34)=3Bfont-family:arial=2C sans-serif=3Bfont-=
size:small=3B">Children always synchronise and follow all parents (and thei=
r reorganisations)=2C and parents are aware of their children. This allows =
you to do some pretty cool things with security. If a child tries to withdr=
aw to a parent after spending on the child (a double spend attempt) this wi=
ll be visible instantly=2C and all child nodes will immediately be able to =
broadcast proof of the double spend to parent chain nodes so they do not mi=
ne on those blocks. This effectively means children can inherit a level of =
security from their parents without the same PoW difficulty.</div><div styl=
e=3D"color:rgb(34=2C 34=2C 34)=3Bfont-family:arial=2C sans-serif=3Bfont-siz=
e:small=3B"><br></div><div style=3D"color:rgb(34=2C 34=2C 34)=3Bfont-family=
:arial=2C sans-serif=3Bfont-size:small=3B">There are so many conflicting vi=
sions for how to scale Bitcoin. Angel allows the free market to decide whic=
h approaches are successful=2C and for complementary blockchains with diffe=
rent use cases=2C such as privacy=2C high transaction volume=2C and Turing =
completeness to more seamlessly exist alongside each other=2C using Bitcoin=
 as the standard medium of exchange.</div><div style=3D"color:rgb(34=2C 34=
=2C 34)=3Bfont-family:arial=2C sans-serif=3Bfont-size:small=3B"><br></div><=
div style=3D"color:rgb(34=2C 34=2C 34)=3Bfont-family:arial=2C sans-serif=3B=
font-size:small=3B">I wrote this as a TLDR summary for a (still evolving) i=
dea I had on the best approach to scale Bitcoin infinitely. I've written mo=
re of my thoughts on the idea at&nbsp=3B<a href=3D"https://seebitcoin.com/2=
016/09/introducing-buzz-a-turing-complete-concept-for-scaling-bitcoin-to-in=
finity-and-beyond/" target=3D"_blank" style=3D"font-family:Calibri=2C sans-=
serif=3Bfont-size:12pt=3B">https://seebitcoin.com/2016/09/introducing-buzz-=
a-turing-complete-concept-for-scaling-bitcoin-to-infinity-and-beyond/</a></=
div><div style=3D"color:rgb(34=2C 34=2C 34)=3Bfont-family:arial=2C sans-ser=
if=3Bfont-size:small=3B"><br></div><div style=3D"color:rgb(34=2C 34=2C 34)=
=3Bfont-family:arial=2C sans-serif=3Bfont-size:small=3B">Does anybody think=
 this would be a better=2C more efficient way of implementing sidechains? I=
t allows infinite scaling=2C and standardisation allows better pooling of r=
esources.</div><div style=3D"color:rgb(34=2C 34=2C 34)=3Bfont-family:arial=
=2C sans-serif=3Bfont-size:small=3B"><br></div><div style=3D"color:rgb(34=
=2C 34=2C 34)=3Bfont-family:arial=2C sans-serif=3Bfont-size:small=3B">Thank=
s=2C</div><div style=3D"color:rgb(34=2C 34=2C 34)=3Bfont-family:arial=2C sa=
ns-serif=3Bfont-size:small=3B"><br></div><div style=3D"color:rgb(34=2C 34=
=2C 34)=3Bfont-family:arial=2C sans-serif=3Bfont-size:small=3B">John Hardy<=
/div><div style=3D"color:rgb(34=2C 34=2C 34)=3Bfont-family:arial=2C sans-se=
rif=3Bfont-size:small=3B">john@seebitcoin.com</div> 		 	   		  </div></div>=
<style><!--=0A=
.ExternalClass .ecxhmmessage P {=0A=
padding:0px=3B=0A=
}=0A=
=0A=
.ExternalClass body.ecxhmmessage {=0A=
font-size:12pt=3B=0A=
font-family:Calibri=3B=0A=
}=0A=
=0A=
--></style> 		 	   		  </div></body>
</html>=

--_d2d1fb10-3faa-4fa4-9dbb-e645565bc877_--