diff options
| author | Gregory Maxwell <gmaxwell@gmail.com> | 2012-06-15 12:53:13 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2012-06-15 16:53:20 +0000 |
| commit | 6b16701fe297743c926f8383904864d5db5e6965 (patch) | |
| tree | ade8c3d9ff72f736142ea11ceeab9622956ed19f | |
| parent | db1affbf5db898fa0a6af7abf16166fe4ca257d0 (diff) | |
| download | pi-bitcoindev-6b16701fe297743c926f8383904864d5db5e6965.tar.gz pi-bitcoindev-6b16701fe297743c926f8383904864d5db5e6965.zip | |
[Bitcoin-development] Near-term scalability
| -rw-r--r-- | 96/ead970b91146bee2e70692cc3b03de130acfc7 | 162 |
1 files changed, 162 insertions, 0 deletions
diff --git a/96/ead970b91146bee2e70692cc3b03de130acfc7 b/96/ead970b91146bee2e70692cc3b03de130acfc7 new file mode 100644 index 000000000..9b003f099 --- /dev/null +++ b/96/ead970b91146bee2e70692cc3b03de130acfc7 @@ -0,0 +1,162 @@ +Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] + helo=mx.sourceforge.net) + by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <gmaxwell@gmail.com>) id 1SfZlw-0005VE-9s + for bitcoin-development@lists.sourceforge.net; + Fri, 15 Jun 2012 16:53:20 +0000 +Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com + designates 209.85.220.175 as permitted sender) + client-ip=209.85.220.175; envelope-from=gmaxwell@gmail.com; + helo=mail-vc0-f175.google.com; +Received: from mail-vc0-f175.google.com ([209.85.220.175]) + by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1SfZlv-0000Um-Bs + for bitcoin-development@lists.sourceforge.net; + Fri, 15 Jun 2012 16:53:20 +0000 +Received: by vcbfl15 with SMTP id fl15so2003489vcb.34 + for <bitcoin-development@lists.sourceforge.net>; + Fri, 15 Jun 2012 09:53:13 -0700 (PDT) +MIME-Version: 1.0 +Received: by 10.221.13.65 with SMTP id pl1mr3363627vcb.61.1339779193827; Fri, + 15 Jun 2012 09:53:13 -0700 (PDT) +Received: by 10.220.199.197 with HTTP; Fri, 15 Jun 2012 09:53:13 -0700 (PDT) +In-Reply-To: <CAAS2fgTJ0UH0Gr6gVMNZwOiv41WzZVesyvNCULj8UfCPPGxQrw@mail.gmail.com> +References: <CANEZrP3w+AiTXmv9Wb3Zi5yyFmGPk82-ysVo4_DVvtg8HHBCdQ@mail.gmail.com> + <CAAS2fgTJ0UH0Gr6gVMNZwOiv41WzZVesyvNCULj8UfCPPGxQrw@mail.gmail.com> +Date: Fri, 15 Jun 2012 12:53:13 -0400 +Message-ID: <CAAS2fgQ8Yo=t+owLWLXeqOKFXcaYcJA4dXube-z9Lh_UeQnuLw@mail.gmail.com> +From: Gregory Maxwell <gmaxwell@gmail.com> +To: Bitcoin Development <bitcoin-development@lists.sourceforge.net> +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable +X-Spam-Score: -1.5 (-) +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 + (gmaxwell[at]gmail.com) + -0.0 SPF_PASS SPF: sender matches SPF record + -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 + 0.1 AWL AWL: From: address is in the auto white-list +X-Headers-End: 1SfZlv-0000Um-Bs +Subject: [Bitcoin-development] Near-term scalability +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: Fri, 15 Jun 2012 16:53:20 -0000 + +[I originally sent an earlier version of this message to Mike off +list, but I figure it's worth adding to the public discussion] + +On Fri, Jun 15, 2012 at 7:29 AM, Mike Hearn <mike@plan99.net> wrote: +> (4) Making the block size limit float is better than picking a new +> arbitrary threshold. +> On the forums Matt stated that block chain pruning was a no-go because +> "it makes bitcoin more centralized". I think we've thrashed this one +> out sufficiently well by now that there should be a united opinion on +> it. + +By itself letting the size float has non-trivial existential risk. =C2=A0A +Bitcoin with expensive transactions due to competition for space in +blocks can be front-ended with fast payment systems and still provide +the promised decentralized currency. Bitcoin with a very large +blockchain and blocks does not. =C2=A0It would do the bitcoin users no good +to increase the transaction volume while concurrently making Bitcoin +more or less pointless over the alternatives. + +Scalability must be improved, we can unite on that opinion. =C2=A0But +scalability can't come at the expense of what made Bitcoin worth +having in the first place. + +Fortunately it appear to be possible to greatly increase the +scalability without compromising on keeping the costs of operating a +fully validating node very low, =C2=A0for example Pieter's experimentation +with txout+txid indexing (for the 'flip the chain' proposals) +indicates that the data required right now to validate further +transactions is only about 85MiB=E2=80=94 and that would be somewhat smalle= +r +with compression and with clients which intentionally try to reduce +the set of unspent transactions. =C2=A0 Commitments to these indexes in the +chain would allow almost-full validating nodes with fairly limited +resources. (Almost-full meaning they would not validate the history +long before they started, they'd trusted header difficulty for that. They +could still mine and otherwise act as full nodes). + +Achieving scalability improvements without breaking the radical +decentralization will be a lot harder than just improving scalability +but it's effort that is justified if the scalability is actually +needed. + +How much decentralization is needed in the end? That isn't clear=E2=80=94 = +"As +much as possible" should generally be the goal. Modern currencies +aren't controlled by single parties but by tens of thousands of +parties locked in economic, legal, and political compromise that +limits their control. In Bitcoin the traditional controls that keep +parties honest are non-existent and if they were just directly applied +we'd potentially lose the properties that make Bitcoin distinct and +useful (e.g. make all miners mine only with FED permission and you +just have a really bandwidth inefficient interface to the dollar). +Instead we have aggressive decentralization and autonomous rule +enforcement. + +Mike pointed out that "Before he left Satoshi made a comment saying +he used to think Bitcoin would need millions of nodes if it became +really popular, but in the end he thought it could do fine with just +tens of thousands" I'm not so sure=E2=80=94 and I think the truth is in +between. Tens of thousands of nodes=E2=80=94 run by a self-selecting bunch= + of +people who reap the greatest rewards from controlling the validation +of Bitcoin, who by that criteria necessarily have a lot in common with +each other and perhaps not with the regular users=E2=80=94 could easily be = +an +outcome where control is _less_ publicly vested than popular +government controlled currencies. We probably don't need the raw +numbers of nodes, but we need a distribution of ownership and a +distribution of interest (e.g. not a system by bankers for bankers) of +those nodes which I think can only be achieved by making them cheap to +operate and having a lot more than we actually need. =E2=80=94 though not s= +o +much that it has to run on every laptop. + +The core challenge is that the only obvious ways to justify the cost +of maintaining expensive validation infrastructure is because you +intend to manipulate the currency using it or because you intend to +prevent other people from manipulating the currency. The latter +motivation is potentially subject to a tragedy of the commons=E2=80=94 you +don't need to run a full validating node as long as 'enough' other +people do, and enough is a nice slippery slope to zero. Right now +just the random computers I=E2=80=94 some random geek=E2=80=94 had at home = +prior to +Bitcoin could store over a hundred years of max size blocks and +process the maximum rate of transactions. With the costs so low +there isn't any real question about a consolidation of validation +making Bitcoin pointless. You could probably increase the scale 10x +without breaking that analysis but beyond that unless the +cost-per-scale goes down a highly consolidated future seems likely. +40 years from now why would people use Bitcoin over centralized +private banknotes like paypal or democratic government controlled +currencies? + +Perhaps Bitcoin transaction could transition to being more of the +same=E2=80=94 controlled by a consortium of banks, exchanging gigabyte bloc= +ks +over terabit ethernet, but I think that would be sad. An alternative +which was autonomous and decentralized even if the transactions were +somewhat slow or costly would be excellent competition for everything +else, and it's something I think man kind ought to have. + + |