path: root/dd/609810aa7d1a5a8c69ad30b2a40fd3357549d3

Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <akaramaoun@gmail.com>) id 1Z3pek-0000I7-S4
	for bitcoin-development@lists.sourceforge.net;
	Sat, 13 Jun 2015 17:55:46 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.213.173 as permitted sender)
	client-ip=209.85.213.173; envelope-from=akaramaoun@gmail.com;
	helo=mail-ig0-f173.google.com; 
Received: from mail-ig0-f173.google.com ([209.85.213.173])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Z3pei-0008Tk-Sn
	for bitcoin-development@lists.sourceforge.net;
	Sat, 13 Jun 2015 17:55:46 +0000
Received: by igbzc4 with SMTP id zc4so30092701igb.0
	for <bitcoin-development@lists.sourceforge.net>;
	Sat, 13 Jun 2015 10:55:39 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.42.163.137 with SMTP id c9mr21937562icy.51.1434218139549;
	Sat, 13 Jun 2015 10:55:39 -0700 (PDT)
Sender: akaramaoun@gmail.com
Received: by 10.64.20.229 with HTTP; Sat, 13 Jun 2015 10:55:39 -0700 (PDT)
In-Reply-To: <CAPg+sBjqQ66f1Rmhi9HOBYP5BDjBHvTNPpUN-y3o-KX8dXBMhg@mail.gmail.com>
References: <CAL8tG==LG=xC_DzOaghbGGKab4=UVpGLQV7781pU4wg+WnFdMg@mail.gmail.com>
	<CAPg+sBjqQ66f1Rmhi9HOBYP5BDjBHvTNPpUN-y3o-KX8dXBMhg@mail.gmail.com>
Date: Sat, 13 Jun 2015 17:55:39 +0000
X-Google-Sender-Auth: tZRtBg3lLhwMekszwedkeMMX9eU
Message-ID: <CAL8tG=kNt0aVkae-z40OTO8wA+dC=X21dHaMYMg1ptAAu2YVow@mail.gmail.com>
From: Andrew <onelineproof@gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: multipart/alternative; boundary=90e6ba6e8166bd06b9051869eebb
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(akaramaoun[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1Z3pei-0008Tk-Sn
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Scaling Bitcoin with Subchains
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Sat, 13 Jun 2015 17:55:46 -0000

--90e6ba6e8166bd06b9051869eebb
Content-Type: text/plain; charset=UTF-8

First of all, I added more info to bitcointalk.org:
https://bitcointalk.org/index.php?topic=1083345.0

On Sat, Jun 13, 2015 at 2:39 PM, Pieter Wuille <pieter.wuille@gmail.com>
wrote:

>
> In your proposal, transactions go to a chain based the addresses involved.
> We can reasonably assume that different people's wallet will tend to be
> distributed uniformly over several sidechains to hold their transactions
> (if they're not, there is no scaling benefit anyway...). That means that
> for an average transaction, you will need a cross-chain transfer in order
> to get the money to the recipient (as their wallet will usually be
> associated to a chain that is different from your own). Either you use an
> atomic swap (which actually means you end up briefly with coins in the
> destination chain, and require multiple transactions and a medium delay),
> or you use the 2way peg transfer mechanism (which is very slow, and reduces
> the security the recipient has to SPV).
>
> Whatever you do, the result will be that most transactions are:
> * Slower (a bit, or a lot, depending on what mechanism you use).
> * More complex, with more failure modes.
> * Require more and larger transactions (causing a total net extra load on
> all verifiers together).
>
> And either:
> * Less secure (because you rely on a third party to do an atomic swap
> with, or because of the 2 way peg transfer mechanism which has SPV security)
> * Doesn't offer any scaling benefit (because the recipient needs to fully
> validate both his own and the receiver chain).
>
> In short, you have not added any scaling at all, or reduced the security
> of the system significantly, as well as made it significantly less
> convenient to use.
>
> So no, sidechains are not a direct means for solving any of the scaling
> problems Bitcoin has. What they offer is a mechanism for easier
> experimentation, so that new technology can be built and tested without
> needing to introduce a new currency first (with the related speculative and
> network effect problems). That experimentation could eventually lead us to
> discover mechanisms for better scaling, or for more scalability/security
> tradeoffs (see for example the Witness Segregation that Elements Alpha has).
>

Thanks Pieter for your reply. The chain the transaction goes to does not
have to be based on the address (there can be a way for the protocol to
choose), but ya, the address scheme can be a good default. As I said, there
will be an incentive for empty chains to fill up since they will require
less fees (so the scaling benefit isn't dependent on a uniform distribution
of addresses).

The rule I mentioned is that at most 2 different chains can be involved in
one transaction. From a chain to itself is easy. From a parent or
grandparent chain to its child or grandchild chain, is also easy since the
child/grandchild always trusts its parent/grandparent. From a
child/grandchild to parent/grandparent, is also easy (no delay) since the
parent/grandparent will commit to its children (which recursively commit to
their children). As mentioned I am just doing a form of block extensions as
Adam Back described; the chains are not independent. From one chain to
another chain at the same level (sibling chains), the transaction is
recorded on both sibling chains (yes there is some duplication but this is
limited by requiring at most 2 sibling chains participating in a
transaction). They both have to be consistent and this will be ensured by
the miners of their parent chain (those miners will commit to their blocks).

So no, I don't see how it's slower, except that there needs to be some
delay for communication between children/grandchildren and
parents/grandparents, of time O(log n) where n is the number of levels.
Even a small number of levels corresponds to a large transaction volume: n
= 5 corresponds to the equivalent of 625 MB blocks.

Security-wise, it is true that the top level chain will likely have higher
security (more hash power), but at least you can fine tune the fees you pay
according to what level of security is acceptable to you, and as Bitcoin
grows, level 2,3,4 chains can be regarded as almost as secure as the level
1 chain, since there will still be a lot of hash power on them. And anyone
can run a full node on their chains of interest, so there is no SPV level
security here, it is full level security.

Transactions are not significantly different. Miners just have to deal with
child chains, but if there is a scaling benefit, we should not be scared of
complexity. It is probably the simplest way I can think of scaling.

The recipient will validate their own chain fully and will just need the
headers of the relevant parent chains to see whether an output from the
other chain involved in a transaction is really valid. They can also get
the headers of the sibling chain involved in the transaction if they want
to validate the work of the miners on these parent chains. They don't need
the full blocks of the parent and sibling chains involved since not all the
transactions in those blocks may be of interest to them, they just need
proof that any output used in their blocks of interest are valid, so that's
why the header-only SPV proof is sufficient. But yeah, typically a user
will have the full blocks of the parent and grandparent chains of the
chains they are interested in tracking, but it is not always necessary.

Also, in the bitcointalk forum I explain in more detail the mining
procedure and how to limit the extra traffic that may be caused on the
network in case this does get added as a soft fork and then later a new
better scaling method is invented that supercedes this.

But basically, for the mining, I think it should be merge-mined between
parent and direct children only. If all the chains are merge mining the
same root chain, then it would be bad for decentralization, right? But with
only direct parent and children merge mining, you can have smaller miners
on the lower (grand children) level chains and since they will need to
solve another hash problem than their grand parent chains, the grandparents
cannot solve blocks in the grand children chains (only the direct children).

So I still didn't hear a good argument against my proposal. I know Adam
Back's form of extension blocks is problematic because it still has the big
blocks, just at another level of chain, but just by partitioning his one 10
MB chain into 10 pieces, you get my idea, which I think solves the
scalability problem as well.

Cheers

-- 
PGP: B6AC 822C 451D 6304 6A28  49E9 7DB7 011C D53B 5647

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

<div dir=3D"ltr"><div>First of all, I added more info to <a href=3D"http://=
bitcointalk.org">bitcointalk.org</a>: <a href=3D"https://bitcointalk.org/in=
dex.php?topic=3D1083345.0">https://bitcointalk.org/index.php?topic=3D108334=
5.0</a><br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Sat, Jun 13, 2015 at 2:39 PM, Pieter Wuille <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:pieter.wuille@gmail.com" target=3D"_blank">pieter.wuille@gmail.=
com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><span class=3D""></span><br><div class=3D"gmail_quote"><span class=3D""><=
/span><div>In your proposal, transactions go to a chain based the addresses=
 involved. We can reasonably assume that different people&#39;s wallet will=
 tend to be distributed uniformly over several sidechains to hold their tra=
nsactions (if they&#39;re not, there is no scaling benefit anyway...). That=
 means that for an average transaction, you will need a cross-chain transfe=
r in order to get the money to the recipient (as their wallet will usually =
be associated to a chain that is different from your own). Either you use a=
n atomic swap (which actually means you end up briefly with coins in the de=
stination chain, and require multiple transactions and a medium delay), or =
you use the 2way peg transfer mechanism (which is very slow, and reduces th=
e security the recipient has to SPV).<br><br></div><div>Whatever you do, th=
e result will be that most transactions are:<br></div><div>* Slower (a bit,=
 or a lot, depending on what mechanism you use).<br></div><div>* More compl=
ex, with more failure modes.<br></div><div>* Require more and larger transa=
ctions (causing a total net extra load on all verifiers together).<br></div=
><div><br></div><div>And either:<br></div><div>* Less secure (because you r=
ely on a third party to do an atomic swap with, or because of the 2 way peg=
 transfer mechanism which has SPV security)<br></div><div>* Doesn&#39;t off=
er any scaling benefit (because the recipient needs to fully validate both =
his own and the receiver chain).<br><br></div><div>In short, you have not a=
dded any scaling at all, or reduced the security of the system significantl=
y, as well as made it significantly less convenient to use.<br><br></div><d=
iv>So no, sidechains are not a direct means for solving any of the scaling =
problems Bitcoin has. What they offer is a mechanism for easier experimenta=
tion, so that new technology can be built and tested without needing to int=
roduce a new currency first (with the related speculative and network effec=
t problems). That experimentation could eventually lead us to discover mech=
anisms for better scaling, or for more scalability/security tradeoffs (see =
for example the Witness Segregation that Elements Alpha has).<span class=3D=
"HOEnZb"><font color=3D"#888888"><br></font></span><span class=3D"HOEnZb"><=
/span></div></div></div>
</blockquote></div><br></div><div class=3D"gmail_extra">Thanks Pieter for y=
our reply. The chain the transaction goes to does not have to be based on t=
he address (there can be a way for the protocol to choose), but ya, the add=
ress scheme can be a good default. As I said, there will be an incentive fo=
r empty chains to fill up since they will require less fees (so the scaling=
 benefit isn&#39;t dependent on a uniform distribution of addresses).<br></=
div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">The rul=
e I mentioned is that at most 2 different chains can be involved in one tra=
nsaction. From a chain to itself is easy. From a parent or grandparent chai=
n to its child or grandchild chain, is also easy since the child/grandchild=
 always trusts its parent/grandparent. From a child/grandchild to parent/gr=
andparent, is also easy (no delay) since the parent/grandparent will commit=
 to its children (which recursively commit to their children). As mentioned=
 I am just doing a form of block extensions as Adam Back described; the cha=
ins are not independent. From one chain to another chain at the same level =
(sibling chains), the transaction is recorded on both sibling chains (yes t=
here is some duplication but this is limited by requiring at most 2 sibling=
 chains participating in a transaction). They both have to be consistent an=
d this will be ensured by the miners of their parent chain (those miners wi=
ll commit to their blocks).<br><br></div><div class=3D"gmail_extra">So no, =
I don&#39;t see how it&#39;s slower, except that there needs to be some del=
ay for communication between children/grandchildren and parents/grandparent=
s, of time O(log n) where n is the number of levels. Even a small number of=
 levels corresponds to a large transaction volume: n =3D 5 corresponds to t=
he equivalent of 625 MB blocks.<br><br></div><div class=3D"gmail_extra">Sec=
urity-wise, it is true that the top level chain will likely have higher sec=
urity (more hash power), but at least you can fine tune the fees you pay ac=
cording to what level of security is acceptable to you, and as Bitcoin grow=
s, level 2,3,4 chains can be regarded as almost as secure as the level 1 ch=
ain, since there will still be a lot of hash power on them. And anyone can =
run a full node on their chains of interest, so there is no SPV level secur=
ity here, it is full level security.<br><br></div><div class=3D"gmail_extra=
">Transactions are not significantly different. Miners just have to deal wi=
th child chains, but if there is a scaling benefit, we should not be scared=
 of complexity. It is probably the simplest way I can think of scaling.<br>=
<br></div><div class=3D"gmail_extra">The recipient will validate their own =
chain fully and will just need the headers of the relevant parent chains to=
 see whether an output from the other chain involved in a transaction is re=
ally valid. They can also get the headers of the sibling chain involved in =
the transaction if they want to validate the work of the miners on these pa=
rent chains. They don&#39;t need the full blocks of the parent and sibling =
chains involved since not all the transactions in those blocks may be of in=
terest to them, they just need proof that any output used in their blocks o=
f interest are valid, so that&#39;s why the header-only SPV proof is suffic=
ient. But yeah, typically a user will have the full blocks of the parent an=
d grandparent chains of the chains they are interested in tracking, but it =
is not always necessary.<br><br></div><div class=3D"gmail_extra">Also, in t=
he bitcointalk forum I explain in more detail the mining procedure and how =
to limit the extra traffic that may be caused on the network in case this d=
oes get added as a soft fork and then later a new better scaling method is =
invented that supercedes this.<br><br></div><div class=3D"gmail_extra">But =
basically, for the mining, I think it should be merge-mined between parent =
and direct children only. If all the chains are merge mining the same root =
chain, then it would be bad for decentralization, right? But with only dire=
ct parent and children merge mining, you can have smaller miners on the low=
er (grand children) level chains and since they will need to solve another =
hash problem than their grand parent chains, the grandparents cannot solve =
blocks in the grand children chains (only the direct children).<br><br></di=
v><div class=3D"gmail_extra">So I still didn&#39;t hear a good argument aga=
inst my proposal. I know Adam Back&#39;s form of extension blocks is proble=
matic because it still has the big blocks, just at another level of chain, =
but just by partitioning his one 10 MB chain into 10 pieces, you get my ide=
a, which I think solves the scalability problem as well.<br><br></div><div =
class=3D"gmail_extra">Cheers<br clear=3D"all"></div><div class=3D"gmail_ext=
ra"><br>-- <br><div class=3D"gmail_signature">PGP: B6AC 822C 451D 6304 6A28=
 =C2=A049E9 7DB7 011C D53B 5647</div>
</div></div>

--90e6ba6e8166bd06b9051869eebb--