From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Yqbqg-0000hz-Sg for bitcoin-development@lists.sourceforge.net; Fri, 08 May 2015 06:33:26 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of riseup.net designates 198.252.153.129 as permitted sender) client-ip=198.252.153.129; envelope-from=necronomics@riseup.net; helo=mx1.riseup.net; Received: from mx1.riseup.net ([198.252.153.129]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1Yqbqf-0008Ke-3x for bitcoin-development@lists.sourceforge.net; Fri, 08 May 2015 06:33:26 +0000 Received: from berryeater.riseup.net (berryeater-pn.riseup.net [10.0.1.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.riseup.net (Postfix) with ESMTPS id 1A9A44119F for ; Fri, 8 May 2015 06:33:19 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: arkady) with ESMTPSA id F03E641FEC MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 08 May 2015 06:33:18 +0000 From: Arkady To: Bitcoin Dev In-Reply-To: <20150508000556.GA16794@savin.petertodd.org> References: <554BE0E1.5030001@bluematt.me> <20150508000556.GA16794@savin.petertodd.org> Message-ID: <4726ecd29577c6271e9e9dfdc5fc2a86@riseup.net> X-Sender: necronomics@riseup.net User-Agent: Riseup mail X-Virus-Scanned: clamav-milter 0.98.6 at mx1 X-Virus-Status: Clean X-Spam-Score: -1.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 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [198.252.153.129 listed in list.dnswl.org] -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -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.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines X-Headers-End: 1Yqbqf-0008Ke-3x Subject: Re: [Bitcoin-development] Block Size Increase Requirements 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, 08 May 2015 06:33:26 -0000 --[remove this line and above]-- On Thu, 7 May 2015, Gregory Maxwell wrote: > Date: Thu, 7 May 2015 00:37:54 +0000 > From: Gregory Maxwell > To: Matt Corallo > Cc: Bitcoin Dev > Subject: Re: [Bitcoin-development] Block Size Increase > > Thanks Matt; I was actually really confused by this sudden push with > not a word here or on Github--so much so that I responded on Reddit to > people pointing to commits in Gavin's personal repository saying they > were reading too much into it. I saw this. I was also pointing this out to the people who were asking me. A commit to a personal repository does not at first seem more than experimental. sipa commits weird/neat things to private branches all the time, after all. > to share behavior. In the case of mining, we're trying to optimize the > social good of POW security. (But the analogy applies in other ways > too: About the only argument IMO in favour of block size increases is to assume that making more room in a block will make it attractive to use for more people at some point in the future: increasing transaction velocity, increasing economy size, increasing value overall. > increases to the chain side are largely an externality; miners enjoy > the > benefits, everyone else takes the costs--either in reduced security or > higher node operating else.) Who else but miners and pool operators will run full nodes when full nodes are being shut down because they are too large and unwieldy to maintain? It is already so that casual users refuse to run full nodes. This fact is indisputable. The only question remaining is, "Do we care?" Arguments against users who feel that the dataset is too large to run a full node, full-time, start from a premise that these users are a static and irrelevant fraction. Is this even true? "Do we care?" I do. I will shortly only be able to run half the nodes I currently do thanks to the growth of the blockchain at its current rate. > One potential argument is that maybe miners would be _regulated_ to > behave correctly. But this would require undermining the openness of > the > system--where anyone can mine anonymously--in order to enforce > behavior, > and that same enforcement mechanism would leave a political level to > impose additional rules that violate the extra properties of the > system. I would refuse to mine under such a regulated regime; moreover, I would enjoy forking away from this, and, I suspect, the only miners who remain would be those whose ultimate motivations do not coincide with the users. That is, the set of miners who are users, and the set of users who are miners, would be wholly non-intersecting. > So far the mining ecosystem has become incredibly centralized over > time. This is unfortunate but true. > of the regular contributors to Bitcoin Core do. Many participants > have never mined or only did back in 2010/2011... we've basically > ignored the mining ecosystem, and this has had devastating effects, > causing a latent undermining of the security model: hacking a dozen or > so computers--operated under totally unknown and probably not strong > security policies--could compromise the network at least at the tip... The explicit form of the block dictated by the reference client and agreed-to by the people who were sold on bitcoin near the beginning (myself included) was explicitly the notion that the rules were static; that the nature of transaction foundations and the subsidies would not be altered. Here we have a hardfork being contemplated which is not only controversial, but does not even address some of the highest-utility and most-requested features in peoples' hardfork wishlists. The fact that mining has effectively been centralized directly implies that destabilizing changes that some well-heeled (and thus theoretically capable, at least) people have explicitly begun plans to fork the blockchain about will have an unknown, and completely unforeseen combined effect. We can pretend that, "If merchants and miners and exchanges go along, then who else matters," but the reality is that the value in bitcoin exists because *people* use it for real transactions: Not miners, whose profits are parasitically fractionally based on the quality and strength of the bitcoin economy as a whole; not exchanges who lubricate transactions in service to the economy; not even today's merchants whose primary means of accepting bitcoin seems to be to convert them instantly to fiat and not participate meaningfully in the economy at all; not enriched felons; but actual users themselves. > Rightfully we should be regarding this an an emergency, and probably > should have been have since 2011. There are two ways to look at it, assuming that the blocksize change increases bitcoin's value to people after all: mining centralization will be corrected; or, mining centralization will not be corrected. I would argue that rapidly increasing profitability at this point will exacerbate the mining centralization problem, and in much the same way as when people were throwing money and unknowingly funding the massive frauds of the current cabals when bitcoin's exchange-driven rise to $1200 was first realized. Thus, even if the premise were true, what will a blocksize increase achieve given mining centralization itself is a bigger systemic risk? > Hardfork changes should only be made if they're almost completely > uncontroversial--where virtually everyone can look at the available > data > and say "yea, that isn't undermining my property rights or future use > of Bitcoin; it's no big deal". The recent "revelation" that there are masses of paid trolls on popular forum sites like reddit who supposedly don't even know who is hiring them, and the anger of more vociferous commenters in general, does not invalidate the relevance of every non-"industry" voice. I think elevating the discussion away from the users does the system and the development process as a whole quite an injustice. > I'm curious as to what discussions people have seen; e.g., are people > even here aware of these concerns? Are you aware of things like the > hashcash mediated dynamic blocksize limiting? I have seen most of these; or the ideas seem obvious based on their names. > About proposals like lightning network (instant transactions and > massive > scale, in exchange for some short term DOS risk if a counterparty opts > out)? Do people (other than Mike Hearn; I guess) think a future where > everyone depends on a small number of "Google scale" node operations > for > the system is actually okay? (I think not, and if so we're never going > to > agree--but it can be helpful to understand when a disagreement is > ideological). It is not okay. If the current mining cabals continue to exist, and flourish, and the developers make major changes that ignore this glaring elephant, then the decentralized promise of bitcoin will be put more at risk. signmessage 1DdcrjT9Yqb6U58wVMA2e7untFbz2rmZd4 "49786791f4d0a260689867ccdfb2cc5b8460984e335504444ade113d2768505c" G6NPl7Wklo9lcdgeVI2H2pexzgqD0KPHhI/wAe32DBm8m59Qf31j5d4tsx5drcql/8wPeIb0QGarr/o4VIOLLGE= --[remove this line and below]-- HHsTfiZ/S7+GNYRwws+QyAr+6/MgDz0Jyntl7CAvjhdfzbnwPorybQUXxRw3CE4DgYgAy1zLanE8H/5NK+l3UlE=