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 ) 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 ; 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: References: Date: Fri, 15 Jun 2012 12:53:13 -0400 Message-ID: From: Gregory Maxwell To: Bitcoin Development 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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.