path: root/61/fb43d535e676451cc135620e88d1770de64528

Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <akaramaoun@gmail.com>) id 1YuuAl-0003FH-UX
	for bitcoin-development@lists.sourceforge.net;
	Wed, 20 May 2015 02:55:55 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.213.171 as permitted sender)
	client-ip=209.85.213.171; envelope-from=akaramaoun@gmail.com;
	helo=mail-ig0-f171.google.com; 
Received: from mail-ig0-f171.google.com ([209.85.213.171])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1YuuAk-00061u-Ct
	for bitcoin-development@lists.sourceforge.net;
	Wed, 20 May 2015 02:55:55 +0000
Received: by igbhj9 with SMTP id hj9so50446299igb.1
	for <bitcoin-development@lists.sourceforge.net>;
	Tue, 19 May 2015 19:55:49 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.107.9.88 with SMTP id j85mr13650113ioi.39.1432090549053;
	Tue, 19 May 2015 19:55:49 -0700 (PDT)
Sender: akaramaoun@gmail.com
Received: by 10.64.20.229 with HTTP; Tue, 19 May 2015 19:55:49 -0700 (PDT)
Date: Wed, 20 May 2015 02:55:49 +0000
X-Google-Sender-Auth: wG6IcXL2ukEEYAIFWAEv8Bms6rY
Message-ID: <CAL8tG==LG=xC_DzOaghbGGKab4=UVpGLQV7781pU4wg+WnFdMg@mail.gmail.com>
From: Andrew <onelineproof@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a113f8d3476724a05167a905e
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.0 AC_DIV_BONANZA RAW: Too many divs in a row... spammy template
	-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: 1YuuAk-00061u-Ct
Subject: [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: Wed, 20 May 2015 02:55:56 -0000

--001a113f8d3476724a05167a905e
Content-Type: text/plain; charset=UTF-8

Hi

I briefly mentioned something about this on the bitcoin-dev IRC room. In
general, it seems experts (like sipa i.e. Pieter) are against using
sidechains as a way of scaling. As I only have a high level understanding
of the Bitcoin protocol, I cannot be sure if what I want to do is actually
defined as a side chain, but let me just propose it, and please let me know
whether it can work, and if not why not (I'm not scared of digging into
more technical resources in order to fully understand). I do have a good
academic/practical background for Bitcoin, and I'm ready to contribute code
if needed (one of my contributions includes a paper wallet creator written
in C).

The main problem I see with increasing the block size limit is that it
increases the amount of storage required to fully validate all transactions
for say 100 years (a person's life). With 1 MB blocks, you can store all
lifetime transactions on a 5 TB drive, which basically any regular user can
do. With 10 MB blocks, you need a 50 TB drive, not accessible for regular
users. Yes, it's possible that in the future hard drive technology will get
cheaper and smaller, but this still didn't happen, so we can't just say "it
should be doable at the rate of Moore's law etc...", we need to know that
it is accessible for everyone, now. Also, don't forget that human life
expectancy can increase with time as well. I know, it sounds silly to use a
human lifetime as a measurement of how far back each user should be able to
store transactions for, but what is a better measurement? This is a
technology made for people i.e. humans, right, and the important part is
that it is for regular people and not just well privileged people. You can
search my last four emails for some more calculations.

What sipa told me on the IRC channel is that Bitcoin Core does not care
about old transactions. It only looks at the current blocks. Yes, that
makes sense, but how do you know that your machine wasn't compromised when
validating the previous blocks? And what if you want to check some old
transactions (assuming you didn't index everything)? What if some of your
old transaction data was lost or corrupted? I think it is clear that it is
useful to be able to validate all blocks (since 100 years) rather than just
a pruned part. It empowers people to have as much information about Bitcoin
transactions as do large data centers; transactions that may include
government or corporate corruption. This is the key to how Bitcoin enables
transparency for those who should be transparent (individual users with
private addresses can still remain anonymous). Also, 5 TB takes about 20
days to sync starting fresh, on a regular computer, so it allows easy entry
into the system.

So assuming we agree that people should be able to store ~ a lifetime of
transactions, then we need 1 MB blocks. But of course, this leads to huge
transaction costs, and small purchases will be out of limits. So to fix
this, I propose adding a 10 1 MB chains below the main chain (sorry on the
IRC room I said 10 10 MB chains by mistake), so effectively, you have a new
10 MB chain that is partitioned into 10 parts. You can also add a third
level: 100 1 MB chains, and keep going like that. The idea is that when you
make a large transaction, you put it through the top chain; when you make a
medium sized transaction, you put it through one of the middle chains,
which will be verified (mined) by the middle chain, and the top chain will
verify the aggregate transactions of the middle chain. If you have a small
sized transaction, you put it through one of the bottom chains, the bottom
chain verifies it, the middle chain verifies the aggregate transactions of
the bottom chain, and the top chain verifies the aggregate transactions of
the middle chain. By aggregate transaction, I mean the net result of
multiple transactions, and I suppose it can be 20 transactions belonging
only to one "sibling" chain for level 2, or 200 transactions for level 3,
etc...

Now, how does the system decide to which of the 10 chains the middle sized
transaction goes to? I propose just taking some simple function of the
input addresses mod 10, so that you can just keep randomly generating a
wallet until you get one with only addresses that map to only one of the 10
chains (even distribution), so that someone can choose one of the 10
chains, and store only the transactions that belong to that chain. They
should also choose a chain from level 3, etc... So in effect, they will be
storing a chain with block size O(n) where n is the number of levels. They
may store multiple sibling chains at one level, if they want to track of
other people's transactions, such as those of their government MP, or
perhaps, they want to have a separate identity that would be more anonymous
with a separate series of sibling chains. This will increase the storage
size, but the increase will be proportional to the number of things you
want to keep track of (at least this kind of system gives you the ability
to fine tune your storage needs to the level of "things" you want to keep
track of). Also, note that there may likely be duplication of transactions,
since transactions can include addresses that are associated with different
silbling chains, but this effect shouldn't make a big difference, and again
will depend on the complexity of the transactions you want to keep track of.

So how can this work? I propose that we keep the current chain as the top
chain, and then create 10 level 2 chains that also store Bitcoin and the
Bitcoin can be transferred between chains (I think this is the idea of
sidechains). How can we incentivize people to keep mining on the level 1
chain? Perhaps force it into the (soft fork) protocol that anyone mining on
level 2, has to also mine on level 1, and in general, anyone mining on
level n+1 has to also mine on levels n,n-1,...,1. Also, level 1 will have
the best decentralization, so there should be enough people paying fees to
get transactions there for their large transactions that require a high
level of security and trust. Even if people stop using level 1, any bitcoin
you own in the level 1 chain, can be transferred to level 2, and still you
have 1 MB blocks due to the partitioning scheme. How to prevent
transactions from clustering on one or a  few sibling chains in a
particular level? Well the more empty chains should have lower fees, so
that should incentivize people... Note: This system also allows for the
fine tuning of the transaction size to security ratio. Yes the lower chains
will be less secure, but a lower sized transaction does not need as much
security.

For instant transactions, there can also be Lightning channels linked to
whatever level of chain you want.

OK so it seems to me that this can work and would only require a soft fork.
But, as I said, I only have a high level understanding of the Bitcoin
protocol, so it feels kind of too good to be true, and I am ready for heavy
criticism. I am only writing this because I care about Bitcoin and I want
it to remain decentralized and become the best that it can be. I think it
is important to do the right thing rather than (as most people naturally
do) the most convenient thing.

Thanks

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

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

<div dir=3D"ltr"><div><div><div><div><div><div><div><div>Hi<br><br></div>I =
briefly mentioned something about this on the bitcoin-dev IRC room. In gene=
ral, it seems experts (like sipa i.e. Pieter) are against using sidechains =
as a way of scaling. As I only have a high level understanding of the Bitco=
in protocol, I cannot be sure if what I want to do is actually defined as a=
 side chain, but let me just propose it, and please let me know whether it =
can work, and if not why not (I&#39;m not scared of digging into more techn=
ical resources in order to fully understand). I do have a good academic/pra=
ctical background for Bitcoin, and I&#39;m ready to contribute code if need=
ed (one of my contributions includes a paper wallet creator written in C).<=
br><br></div>The main problem I see with increasing the block size limit is=
 that it increases the amount of storage required to fully validate all tra=
nsactions for say 100 years (a person&#39;s life). With 1 MB blocks, you ca=
n store all lifetime transactions on a 5 TB drive, which basically any regu=
lar user can do. With 10 MB blocks, you need a 50 TB drive, not accessible =
for regular users. Yes, it&#39;s possible that in the future hard drive tec=
hnology will get cheaper and smaller, but this still didn&#39;t happen, so =
we can&#39;t just say &quot;it should be doable at the rate of Moore&#39;s =
law etc...&quot;, we need to know that it is accessible for everyone, now. =
Also, don&#39;t forget that human life expectancy can increase with time as=
 well. I know, it sounds silly to use a human lifetime as a measurement of =
how far back each user should be able to store transactions for, but what i=
s a better measurement? This is a technology made for people i.e. humans, r=
ight, and the important part is that it is for regular people and not just =
well privileged people. You can search my last four emails for some more ca=
lculations.<br><br></div>What sipa told me on the IRC channel is that Bitco=
in Core does not care about old transactions. It only looks at the current =
blocks. Yes, that makes sense, but how do you know that your machine wasn&#=
39;t compromised when validating the previous blocks? And what if you want =
to check some old transactions (assuming you didn&#39;t index everything)? =
What if some of your old transaction data was lost or corrupted? I think it=
 is clear that it is useful to be able to validate all blocks (since 100 ye=
ars) rather than just a pruned part. It empowers people to have as much inf=
ormation about Bitcoin transactions as do large data centers; transactions =
that may include government or corporate corruption. This is the key to how=
 Bitcoin enables transparency for those who should be transparent (individu=
al users with private addresses can still remain anonymous). Also, 5 TB tak=
es about 20 days to sync starting fresh, on a regular computer, so it allow=
s easy entry into the system.<br><br></div>So assuming we agree that people=
 should be able to store ~ a lifetime of transactions, then we need 1 MB bl=
ocks. But of course, this leads to huge transaction costs, and small purcha=
ses will be out of limits. So to fix this, I propose adding a 10 1 MB chain=
s below the main chain (sorry on the IRC room I said 10 10 MB chains by mis=
take), so effectively, you have a new 10 MB chain that is partitioned into =
10 parts. You can also add a third level: 100 1 MB chains, and keep going l=
ike that. The idea is that when you make a large transaction, you put it th=
rough the top chain; when you make a medium sized transaction, you put it t=
hrough one of the middle chains, which will be verified (mined) by the midd=
le chain, and the top chain will verify the aggregate transactions of the m=
iddle chain. If you have a small sized transaction, you put it through one =
of the bottom chains, the bottom chain verifies it, the middle chain verifi=
es the aggregate transactions of the bottom chain, and the top chain verifi=
es the aggregate transactions of the middle chain. By aggregate transaction=
, I mean the net result of multiple transactions, and I suppose it can be 2=
0 transactions belonging only to one &quot;sibling&quot; chain for level 2,=
 or 200 transactions for level 3, etc...<br><br></div>Now, how does the sys=
tem decide to which of the 10 chains the middle sized transaction goes to? =
I propose just taking some simple function of the input addresses mod 10, s=
o that you can just keep randomly generating a wallet until you get one wit=
h only addresses that map to only one of the 10 chains (even distribution),=
 so that someone can choose one of the 10 chains, and store only the transa=
ctions that belong to that chain. They should also choose a chain from leve=
l 3, etc... So in effect, they will be storing a chain with block size O(n)=
 where n is the number of levels. They may store multiple sibling chains at=
 one level, if they want to track of other people&#39;s transactions, such =
as those of their government MP, or perhaps, they want to have a separate i=
dentity that would be more anonymous with a separate series of sibling chai=
ns. This will increase the storage size, but the increase will be proportio=
nal to the number of things you want to keep track of (at least this kind o=
f system gives you the ability to fine tune your storage needs to the level=
 of &quot;things&quot; you want to keep track of). Also, note that there ma=
y likely be duplication of transactions, since transactions can include add=
resses that are associated with different silbling chains, but this effect =
shouldn&#39;t make a big difference, and again will depend on the complexit=
y of the transactions you want to keep track of.<br><br></div>So how can th=
is work? I propose that we keep the current chain as the top chain, and the=
n create 10 level 2 chains that also store Bitcoin and the Bitcoin can be t=
ransferred between chains (I think this is the idea of sidechains). How can=
 we incentivize people to keep mining on the level 1 chain? Perhaps force i=
t into the (soft fork) protocol that anyone mining on level 2, has to also =
mine on level 1, and in general, anyone mining on level n+1 has to also min=
e on levels n,n-1,...,1. Also, level 1 will have the best decentralization,=
 so there should be enough people paying fees to get transactions there for=
 their large transactions that require a high level of security and trust. =
Even if people stop using level 1, any bitcoin you own in the level 1 chain=
, can be transferred to level 2, and still you have 1 MB blocks due to the =
partitioning scheme. How to prevent transactions from clustering on one or =
a=C2=A0 few sibling chains in a particular level? Well the more empty chain=
s should have lower fees, so that should incentivize people... Note: This s=
ystem also allows for the fine tuning of the transaction size to security r=
atio. Yes the lower chains will be less secure, but a lower sized transacti=
on does not need as much security.<br><br></div><div>For instant transactio=
ns, there can also be Lightning channels linked to whatever level of chain =
you want.<br></div><div><br></div>OK so it seems to me that this can work a=
nd would only require a soft fork. But, as I said, I only have a high level=
 understanding of the Bitcoin protocol, so it feels kind of too good to be =
true, and I am ready for heavy criticism. I am only writing this because I =
care about Bitcoin and I want it to remain decentralized and become the bes=
t that it can be. I think it is important to do the right thing rather than=
 (as most people naturally do) the most convenient thing.<br><br></div>Than=
ks<br clear=3D"all"><div><div><div><div><div><div><div><div><div><div><div>=
<div><br>-- <br><div class=3D"gmail_signature">PGP: B6AC 822C 451D 6304 6A2=
8 =C2=A049E9 7DB7 011C D53B 5647</div>
</div></div></div></div></div></div></div></div></div></div></div></div></d=
iv>

--001a113f8d3476724a05167a905e--