From: Andrew <onelineproof@gmail•com>
To: Mike Hearn <mike@plan99•net>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Scaling Bitcoin with Subchains
Date: Thu, 28 May 2015 02:16:36 +0000 [thread overview]
Message-ID: <CAL8tG=m8kjPT8e5KsyhoGA4ni7Y9VeR=enX24MQVG4Kh0LnBKA@mail.gmail.com> (raw)
In-Reply-To: <CANEZrP1p3FU_0fvGKTDWF95Zns5S6KciayViZWiP6OmcqrQDUA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 7396 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 8310 bytes --]
next prev parent reply other threads:[~2015-05-28 2:16 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-20 2:55 Andrew
2015-05-25 18:15 ` Mike Hearn
2015-05-28 2:16 ` Andrew [this message]
2015-05-28 2:34 ` Bryan Bishop
2015-06-13 14:39 ` Pieter Wuille
2015-06-13 17:55 ` Andrew
2015-06-14 6:55 ` Martin Schwarz
2015-06-15 17:05 ` Andrew
2015-06-15 17:09 ` Pieter Wuille
2015-06-15 17:15 ` Jeff Garzik
2015-06-16 18:17 ` Peter Todd
2015-06-16 18:43 ` Andrew
2015-06-16 19:04 ` Andrew
2015-06-15 17:18 ` Mike Hearn
2015-06-15 18:00 ` Andrew
2015-06-16 15:23 ` Andrew
2015-06-15 18:01 ` Jeff Garzik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAL8tG=m8kjPT8e5KsyhoGA4ni7Y9VeR=enX24MQVG4Kh0LnBKA@mail.gmail.com' \
--to=onelineproof@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=mike@plan99$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox