Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z4Hn8-0007OB-Fl for bitcoin-development@lists.sourceforge.net; Sun, 14 Jun 2015 23:58:18 +0000 X-ACL-Warn: Received: from mout.perfora.net ([74.208.4.196]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1Z4Hn7-0001nB-8z for bitcoin-development@lists.sourceforge.net; Sun, 14 Jun 2015 23:58:18 +0000 Received: from mail-qc0-f173.google.com ([209.85.216.173]) by mrelay.perfora.net (mreueus001) with ESMTPSA (Nemesis) id 0MdMQ9-1YmTxI2W7X-00IRem for ; Mon, 15 Jun 2015 01:58:11 +0200 Received: by qcbfb9 with SMTP id fb9so12383514qcb.1 for ; Sun, 14 Jun 2015 16:58:10 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.140.31.162 with SMTP id f31mr32072257qgf.23.1434326290900; Sun, 14 Jun 2015 16:58:10 -0700 (PDT) Received: by 10.96.20.164 with HTTP; Sun, 14 Jun 2015 16:58:10 -0700 (PDT) In-Reply-To: References: Date: Mon, 15 Jun 2015 01:58:10 +0200 Message-ID: From: Adam Back To: Mike Hearn Content-Type: text/plain; charset=UTF-8 X-Provags-ID: V03:K0:M60MQYmEtzNGK0Z8Ed5zKAcry6WmSt8oEYipszd8iXN/mAgVj82 kHKGtR5nOoxtJTDElFmi/RfOgsNDTEgGjkURxT5mhcBoz2sOjY/lDpGOUZw3m+JnUdDcKMN bMVZM5WRE6BgvxnNUheWx1gJbFJ0Ft6KCeRlHmzRqoEsGX6qxFC8OHE6exTnRT0tWqs93xx MDLzZ56h+YlSKNCevjpcg== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: -0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [74.208.4.196 listed in list.dnswl.org] -0.0 SPF_HELO_PASS SPF: HELO matches SPF record X-Headers-End: 1Z4Hn7-0001nB-8z Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] comments on BIP 100 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: Sun, 14 Jun 2015 23:58:18 -0000 Hi Mike On 15 June 2015 at 00:23, Mike Hearn wrote: >> One thing that is concerning is that few in industry seem inclined to >> take any development initiatives or even integrate a library. > > Um, you mean except all the people who have built more scalable wallets over > the past few years, which is the only reason anyone can even use Bitcoin > from their phone? No slight intended obviously to people who do write actual client code. That was probably insufficiently specific, let me rephrase: I am referring to the trend that much of the industry is built on web2.0 technology using bitcoin via a library in a web scripting language, often with consensus bugs, and even outsourcing and not even running their own full node, so that the service itself offered to their users isn't even SPV secure to the operator. As well as being heavily based on a third-party custody model that is the root cause of the repeated wallet breaches. Some of these companies have a noted tendency not to upgrade or fix code. So I mean this not to call out specific companies, but in the sense that if we're technologists we should be trying to move the technology forward, not just changing parameters which run into an O(n^2) scaling wall or break decentralisation security. And we shouldnt take the above state of affairs as an immutable reality. It can not persist for bitcoin to reach maturity on scale nor security. > I still think you guys don't recognise what you are actually asking for here > - scrapping virtually the entire existing investment in software, wallets > and tools. As I said I dont think we can expect Bitcoin to scale with no further algorithmic improvements. Algorithmic improvements take code. There is reasonable scope to build in an incrementally deployable way, there's plenty of time for people to code, test and opt-in to things, the sky is not falling. Companies do care about scaling, and can invest in the integration and coding implied to improve their products scalability, they have an economic incentive to do it and there is no scalable and safe way todo it without this work. > Computational complexity for the entire network is O(nm) where > n=transactions and m=fully validating nodes. There is no fixed relationships > between those two variables. I am referring to global bandwidth O(n^2) with n=users, or O(n) per user bandwidth cost to the system, while O(nm) is accurate nodes is an internal system concept. Anyway suffice to say the network does not scale O(1) in per user cost. > "Exposing the companies to back-pressure" sounds quite nice and gentle. Let > me rephrase it to be equivalent but perhaps more direct: you mean "breaking > the current software ecosystem to force people into a new, fictional system > that bears little resemblance to the Bitcoin we use today, whether they want > that or not". > > As nothing that has been proposed so far (Lightning, merge mined chains, > extension blocks etc) has much chance of actual deployment any time soon, > that leaves raising the block size limit as the only possible path left. A hard-fork takes a long period of time to deploy due to the non-upgrade risk, people are working on things in the mean-time. There can be a case for some increase to create some breathing room to work on scaling and decentralising tech, I just mean to say that if we do it in isolation, we're not focussing on the big picture. Adam