From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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: References: Date: Thu, 28 May 2015 02:16:36 +0000 X-Google-Sender-Auth: OLZOPdw6OQ1dA86lu3qCKmjZJKs Message-ID: From: Andrew To: Mike Hearn 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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
Hi All

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

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

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.

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'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's why it= 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'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.

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 sp= an the subchains" 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.

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'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's home on a 3D prin= ter 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 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'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 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.

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'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)

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.


On Mon, May 25, 2015 a= t 6:15 PM, Mike Hearn <mike@plan99.net> wrote:
Hi Andrew,

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.

=
Luckily this makes it a great fit for tape backup. Technology th= at can store 185 terabytes per cartridge=C2=A0has already been devel= oped:


<= 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's virt= ually guaranteed that humanity will not hit a storage technology wall in 20= 15.

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 =C2=A049E9 7DB7 011C D53B 5647
--bcaec5196941fac2f505171af2ac--