path: root/db/db1f4b870a1db5e573e9bcaa01529a4e0fc654

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_--