path: root/48/dd64dc874bfa9101efec259f95d287b970c49c

Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <akaramaoun@gmail.com>) id 1YxnNE-00067P-3P
	for bitcoin-development@lists.sourceforge.net;
	Thu, 28 May 2015 02:16:44 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.223.179 as permitted sender)
	client-ip=209.85.223.179; envelope-from=akaramaoun@gmail.com;
	helo=mail-ie0-f179.google.com; 
Received: from mail-ie0-f179.google.com ([209.85.223.179])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1YxnNC-0004Bb-A7
	for bitcoin-development@lists.sourceforge.net;
	Thu, 28 May 2015 02:16:44 +0000
Received: by iesa3 with SMTP id a3so28113337ies.2
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 27 May 2015 19:16:36 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.42.43.199 with SMTP id y7mr6962482ice.12.1432779396659; Wed,
	27 May 2015 19:16:36 -0700 (PDT)
Sender: akaramaoun@gmail.com
Received: by 10.64.20.229 with HTTP; Wed, 27 May 2015 19:16:36 -0700 (PDT)
In-Reply-To: <CANEZrP1p3FU_0fvGKTDWF95Zns5S6KciayViZWiP6OmcqrQDUA@mail.gmail.com>
References: <CAL8tG==LG=xC_DzOaghbGGKab4=UVpGLQV7781pU4wg+WnFdMg@mail.gmail.com>
	<CANEZrP1p3FU_0fvGKTDWF95Zns5S6KciayViZWiP6OmcqrQDUA@mail.gmail.com>
Date: Thu, 28 May 2015 02:16:36 +0000
X-Google-Sender-Auth: OLZOPdw6OQ1dA86lu3qCKmjZJKs
Message-ID: <CAL8tG=m8kjPT8e5KsyhoGA4ni7Y9VeR=enX24MQVG4Kh0LnBKA@mail.gmail.com>
From: Andrew <onelineproof@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=bcaec5196941fac2f505171af2ac
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: 1YxnNC-0004Bb-A7
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: Thu, 28 May 2015 02:16:44 -0000

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

Hi All

I discussed this idea with some other core developers (on IRC) and they
generally seem to agree that it can be done.

It may be equivalent to an idea called "blockchain extensions" but when I
looked it up on bitcointalk.org I didn't see exactly the same proposal I am
making.

One person suggested I should replace the address to chain function with a
protocol addition that allows one to specify the target chain. Yes, this
can also be done without changing the key properties.

One person said that the main problem is that I am not saying anything
specific, and I should address the sidechain problems written about in the
sidechains paper. Well, actually, there is one quite specific thing I am
saying, in case you didn't notice: With this system, the network can
achieve effectively 5^{n-1} MB blocks with each participant only storing n
MB blocks. So for example, you can have effectively a block size of 625 MB
(= 5^4) with each participant only storing 3 MB blocks; or 3.125 GB blocks
with each participant only storing 4 MB blocks. For these calculations, I
am assuming that only two separate sibling chains are involved in a
transaction, so there is a duplication effect that divides in two the
effective size of a given level of blocks (that's why it's 5 instead of 10
as would be without duplication). If you want to involve multiple sibling
chains in one transaction, you can effectively achieve this by performing
multiple transactions involving 2 of the multiple chains. Yes, the fees
would be higher since you have more transactions to make, but it is
reasonable to expect more fees for more complicated transactions, and I
don't think it will result in people clustering on one chain (people who do
these kinds of transactions would probably track multiple chain paths). As
for the problems with sidechains, I think they would be eliminated due to
the child-parent dependence I specified. I also propose the following
additional rule: In case of conflict between parent and child chains (due
to reorganizations), the child chain must choose the consensus of the
parent chain. Also, for transferring from child to parent, the miners on
the parent have the final say, but to make it more clear, they can use the
relative difference of difficulty between their chain and the child chain
to decide how many blocks deep a transaction in the child chain has to be
to be accepted in the parent chain.

Gavin was the only one who disapproved of this, but I am not sure if he
actually read the whole thing that I wrote. He said something along the
line of "the outputs will span the subchains" and when I asked for an
explanation he just said that I need to learn more about things. I stated
to him my willingness to learn, but have yet to get a response from him.

Mike: You should also keep in mind the big picture when it comes to
decentralization. If the hard drives (or tapes) can only be produced by a
small number of large companies like Western Digital or Seagate, then you
can't really count those for a decentralized system. A truly decentralized
system would have the devices needed to participate in (and verify) the
system be easily created by a regular user of the system without relying on
a central power. So for example, the hard drives needed to store the
bitcoin transaction records should be able to be produced at a regular
person's home on a 3D printer starting from just the raw materials. I don't
know how close we are to this ideal, but just pointing out that it needs to
be considered. This is also a reason why I like that Bitcoin uses the
simple SHA sum for mining instead of a more complicated function such as
scrypt. It makes it easier for small scale entities to understand and to
produce the ASIC miners. Also, in addition to the centralization of storage
device manufacturing, one should also consider what would happen if
everyone wanted to have a 5 TB drive at home. What would happen to the
price of hard drives? Keep in mind also that the human population is likely
increasing, so there are less real resources per person... Yes maybe in the
future we can solve these problems, but we still haven't, so let's not
assume they are solved. Also, you mentioned sharing the costs of a hard
drive with other people. Do you mean trusting that others did not
compromise the hard drives? If you want you can do so, but not every
participant should be forced to trust others, a point I think I made
already. And finally, this is all a discussion on the costs of running a
Bitcoin node. Bitcoin is not all that people will use hard drives and
computers for; we need to leave room for other things.

So Mike, I have a question for you. Are you supporting a block size
increase partly due to philosophical reasons (i.e. you believe that regular
people shouldn't have such strong freedom as I want) or do you just not
care so much about the long term future and you just want to get your
Bitcoin related projects up and running with minimal complications? Or is
it a combination of both things? You should disclose this to the people
following your words because they trust you as an experienced professional
with a good reputation, and it would be dishonest to not disclose this to
them. (same goes for Gavin)

Overall, I think this system is the only system that I heard of that can
scale decentralization without a block size increase. Lightning by itself,
for example, requires a block size increase that depends on how many such
Lightning contracts are being made, so relies on people changing the
protocol, which is obviously less secure and robust than a fixed protocol.
But I am not ruling out any other possibilities, so other things should
also be considered. But eventually, we may have to decide how to scale
without knowing for sure whether the chosen scaling method is the ultimate
scaling method. And I think this is a good candidate for that, and also,
can be reversed later on without changing the original protocol before the
softfork. Actually, we can just make nodes advertise whether they support
the soft fork or not, and if a better scaling protocol comes along, those
nodes can switch to advertise the better one. So it is quite a harmless
soft fork to make, in my opinion.


On Mon, May 25, 2015 at 6:15 PM, Mike Hearn <mike@plan99.net> wrote:

> Hi Andrew,
>
> Your belief that Bitcoin has to be constrained by the belief that hardware
> will never improve is extremist, but regardless, your concerns are easy to
> assuage: there is no requirement that the block chain be stored on hard
> disks. As you note yourself the block chain is used for building/auditing
> the ledger. Random access to it is not required, if all you care about is
> running a full node.
>
> Luckily this makes it a great fit for tape backup. Technology that can
> store 185 terabytes *per cartridge* has already been developed:
>
>
> http://www.itworld.com/article/2693369/sony-develops-tape-tech-that-could-lead-to-185-tb-cartridges.html
>
> As you could certainly share costs of a block chain archive with other
> people, the cost would not be a major concern even today. And it's
> virtually guaranteed that humanity will not hit a storage technology wall
> in 2015.
>
> If your computer is compromised then all bets are off. Validating the
> chain on a compromised host is meaningless.
>



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

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

<div dir=3D"ltr"><div><div><div>Hi All<br></div><br></div>I discussed this =
idea with some other core developers (on IRC) and they generally seem to ag=
ree that it can be done.<br><br>It may be equivalent to an idea called &quo=
t;blockchain extensions&quot; but when I looked it up on <a href=3D"http://=
bitcointalk.org">bitcointalk.org</a> I didn&#39;t see exactly the same prop=
osal I am making.<br><br></div><div>One person suggested I should replace t=
he address to chain function with a protocol addition that allows one to sp=
ecify the target chain. Yes, this can also be done without changing the key=
 properties.<br><br></div><div>One person said that the main problem is tha=
t I am not saying anything specific, and I should address the sidechain pro=
blems written about in the sidechains paper. Well, actually, there is one q=
uite specific thing I am saying, in case you didn&#39;t notice: With this s=
ystem, the network can achieve effectively 5^{n-1} MB blocks with each part=
icipant only storing n MB blocks. So for example, you can have effectively =
a block size of 625 MB (=3D 5^4) with each participant only storing 3 MB bl=
ocks; or 3.125 GB blocks with each participant only storing 4 MB blocks. Fo=
r these calculations, I am assuming that only two separate sibling chains a=
re involved in a transaction, so there is a duplication effect that divides=
 in two the effective size of a given level of blocks (that&#39;s why it&#3=
9;s 5 instead of 10 as would be without duplication). If you want to involv=
e multiple sibling chains in one transaction, you can effectively achieve t=
his by performing multiple transactions involving 2 of the multiple chains.=
 Yes, the fees would be higher since you have more transactions to make, bu=
t it is reasonable to expect more fees for more complicated transactions, a=
nd I don&#39;t think it will result in people clustering on one chain (peop=
le who do these kinds of transactions would probably track multiple chain p=
aths). As for the problems with sidechains, I think they would be eliminate=
d due to the child-parent dependence I specified. I also propose the follow=
ing additional rule: In case of conflict between parent and child chains (d=
ue to reorganizations), the child chain must choose the consensus of the pa=
rent chain. Also, for transferring from child to parent, the miners on the =
parent have the final say, but to make it more clear, they can use the rela=
tive difference of difficulty between their chain and the child chain to de=
cide how many blocks deep a transaction in the child chain has to be to be =
accepted in the parent chain.<br><br></div><div>Gavin was the only one who =
disapproved of this, but I am not sure if he actually read the whole thing =
that I wrote. He said something along the line of &quot;the outputs will sp=
an the subchains&quot; and when I asked for an explanation he just said tha=
t I need to learn more about things. I stated to him my willingness to lear=
n, but have yet to get a response from him.<br><br></div><div>Mike: You sho=
uld also keep in mind the big picture when it comes to decentralization. If=
 the hard drives (or tapes) can only be produced by a small number of large=
 companies like Western Digital or Seagate, then you can&#39;t really count=
 those for a decentralized system. A truly decentralized system would have =
the devices needed to participate in (and verify) the system be easily crea=
ted by a regular user of the system without relying on a central power. So =
for example, the hard drives needed to store the bitcoin transaction record=
s should be able to be produced at a regular person&#39;s home on a 3D prin=
ter starting from just the raw materials. I don&#39;t know how close we are=
 to this ideal, but just pointing out that it needs to be considered. This =
is also a reason why I like that Bitcoin uses the simple SHA sum for mining=
 instead of a more complicated function such as scrypt. It makes it easier =
for small scale entities to understand and to produce the ASIC miners. Also=
, in addition to the centralization of storage device manufacturing, one sh=
ould also consider what would happen if everyone wanted to have a 5 TB driv=
e at home. What would happen to the price of hard drives? Keep in mind also=
 that the human population is likely increasing, so there are less real res=
ources per person... Yes maybe in the future we can solve these problems, b=
ut we still haven&#39;t, so let&#39;s not assume they are solved. Also, you=
 mentioned sharing the costs of a hard drive with other people. Do you mean=
 trusting that others did not compromise the hard drives? If you want you c=
an do so, but not every participant should be forced to trust others, a poi=
nt I think I made already. And finally, this is all a discussion on the cos=
ts of running a Bitcoin node. Bitcoin is not all that people will use hard =
drives and computers for; we need to leave room for other things.<br><br>So=
 Mike, I have a question for you. Are you supporting a block size increase =
partly due to philosophical reasons (i.e. you believe that regular people s=
houldn&#39;t have such strong freedom as I want) or do you just not care so=
 much about the long term future and you just want to get your Bitcoin rela=
ted projects up and running with minimal complications? Or is it a combinat=
ion of both things? You should disclose this to the people following your w=
ords because they trust you as an experienced professional with a good repu=
tation, and it would be dishonest to not disclose this to them. (same goes =
for Gavin)<br><br></div><div>Overall, I think this system is the only syste=
m that I heard of that can scale decentralization without a block size incr=
ease. Lightning by itself, for example, requires a block size increase that=
 depends on how many such Lightning contracts are being made, so relies on =
people changing the protocol, which is obviously less secure and robust tha=
n a fixed protocol. But I am not ruling out any other possibilities, so oth=
er things should also be considered. But eventually, we may have to decide =
how to scale without knowing for sure whether the chosen scaling method is =
the ultimate scaling method. And I think this is a good candidate for that,=
 and also, can be reversed later on without changing the original protocol =
before the softfork. Actually, we can just make nodes advertise whether the=
y support the soft fork or not, and if a better scaling protocol comes alon=
g, those nodes can switch to advertise the better one. So it is quite a har=
mless soft fork to make, in my opinion.<br></div><div><br></div></div><div =
class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, May 25, 2015 a=
t 6:15 PM, Mike Hearn <span dir=3D"ltr">&lt;<a href=3D"mailto:mike@plan99.n=
et" target=3D"_blank">mike@plan99.net</a>&gt;</span> wrote:<br><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex"><div dir=3D"ltr">Hi Andrew,<div class=3D"gmail_extra"><d=
iv class=3D"gmail_quote"><div><br></div><div>Your belief that Bitcoin has t=
o be constrained by the belief that hardware will never improve is extremis=
t, but regardless, your concerns are easy to assuage: there is no requireme=
nt that the block chain be stored on hard disks. As you note yourself the b=
lock chain is used for building/auditing the ledger. Random access to it is=
 not required, if all you care about is running a full node.</div><div><br>=
</div><div>Luckily this makes it a great fit for tape backup. Technology th=
at can store 185 terabytes <i>per cartridge</i>=C2=A0has already been devel=
oped:</div><div><br></div><div><a href=3D"http://www.itworld.com/article/26=
93369/sony-develops-tape-tech-that-could-lead-to-185-tb-cartridges.html" ta=
rget=3D"_blank">http://www.itworld.com/article/2693369/sony-develops-tape-t=
ech-that-could-lead-to-185-tb-cartridges.html</a><br></div><div><br></div><=
div>As you could certainly share costs of a block chain archive with other =
people, the cost would not be a major concern even today. And it&#39;s virt=
ually guaranteed that humanity will not hit a storage technology wall in 20=
15.</div><div><br></div><div>If your computer is compromised then all bets =
are off. Validating the chain on a compromised host is meaningless.</div></=
div></div></div>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail_sig=
nature">PGP: B6AC 822C 451D 6304 6A28 =C2=A049E9 7DB7 011C D53B 5647</div>
</div>

--bcaec5196941fac2f505171af2ac--