Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 7F1688D8 for ; Tue, 11 Aug 2015 21:31:51 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 82C1B109 for ; Tue, 11 Aug 2015 21:31:50 +0000 (UTC) Received: by wicja10 with SMTP id ja10so1787817wic.1 for ; Tue, 11 Aug 2015 14:31:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RwqZ0sUxccSfpE3j/M+xFhIhJUjtgscnhTfu7O/rCAE=; b=qCNqEST03UJQxZzGcsyIseS1o8oGXdIlHjP4FjH+DyquVhy5/zH8jbv4quNfwiQ+6k 0nDJOygzFjc97jJeipZ0w2Uk5XFsxF+rgAMDAGpTKJI/WTU944ORRNydzlzAaH15E3UW w1NI44JLWtqI9/1BfGuwWwyBIn4ZHT2F1X7mLuV4GXruWeW4APsauWk1DgiTnryYI4+b P1L+Dowx7/PIh1PJqAvUCmhOPMUcgeFteYw5snKL0qlIrrRqPMwt6f2ySRPZEVofrQrr FxgngsycYuOGdpiPgxqcuMJAv9QFN6qa0wuy+fWYZhmi5zEyuMiqOcnDqSRGTLZHZLSL OM8w== MIME-Version: 1.0 X-Received: by 10.194.118.197 with SMTP id ko5mr60141068wjb.58.1439328709335; Tue, 11 Aug 2015 14:31:49 -0700 (PDT) Received: by 10.27.78.207 with HTTP; Tue, 11 Aug 2015 14:31:49 -0700 (PDT) In-Reply-To: References: <8181630.GdAj0CPZYc@coldstorage> Date: Tue, 11 Aug 2015 16:31:49 -0500 Message-ID: From: Michael Naber To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= Content-Type: multipart/alternative; boundary=089e0122aec86f6032051d0fd40e X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] Fees and the block-finding process X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 21:31:51 -0000 --089e0122aec86f6032051d0fd40e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Re: "In my opinion the main source of disagreement is that one: how the maximum block size limits centralization." I generally agree with that, but I would add that centralization is only a goal insofar as it serves things like reliability, transaction integrity, capacity, and accessibility. More broadly: how do you think that moving the block size from 1MB to 8MB would materially impact these things? Re: "That's why I cannot understand the urgency to rise the maximum size." This issue is urgent because the difference between bitcoin being a success and it being forgotten hinges on it being "better money" than other money. If people want a money that can process lots and lots of transactions at low cost, they're going to get it so long as technology can give it to them. While it's not critical we raise the block size this very moment since we're not hitting the capacity wall right now, based on the way growth spikes in Bitcoin have occurred in the past we, may hit that capacity wall soon and suddenly. And the moment we do, then Bitcoin may no longer be "better money" since there's a big opportunity for other money with higher throughput and lower fees to take its place. On Tue, Aug 11, 2015 at 2:45 PM, Jorge Tim=C3=B3n wrote: > > On Aug 11, 2015 8:55 PM, "Michael Naber" wrote: > > > > It generally doesn't matter that every node validate your coffee > transaction, and those transactions can and will probably be moved onto > offchain solutions in order to avoid paying the cost of achieving global > consensus. But you still don't get to set the cost of global consensus > artificially. Market forces will ensure that supply will meet demand ther= e, > so if there is demand for access to global consensus, and technology exis= ts > to meet that demand at a cost of one cent per transaction -- or whatever > the technology-limited cost of global consensus happens to be -- then > that's what the market will supply. > > Assuming we maintain any block size maximum consensus rule, the market > will adapt to whatever maximum size is imposed by the consensus rules. > For example, with the current demand and the current consensus block size > maximum, the market has settled on a minimum fee of zero satoshis per > transaction. That's why I cannot understand the urgency to rise the maxim= um > size. > > In any case, yhe consensus maximum shouldn't be based on current or > projected demand, only on centralization concerns, which is what the > consensus rule serves for (to limit centralization). > For example, Gavin advocates for 20 MB because he is not worried about ho= w > that could increase centralization because he believes it won't. > I can't agree with that because I believe 20 MB could make mining > centralization (and centralization in general) much worse. > > But if I have to chose between 2 "centralization safe" sizes, sure, the > bigger the better, why not. > In my opinion the main source of disagreement is that one: how the maximu= m > block size limits centralization. > --089e0122aec86f6032051d0fd40e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Re: "In my opinion the main source of disagreement is that one: how the maximu= m block size limits centralization."

I= generally agree with that, but I would add that centralization is only a g= oal insofar as it serves things like reliability, transaction integrity, ca= pacity, and accessibility. More broadly: how do you think that moving the b= lock size from 1MB to 8MB would materially impact these things?
<= br>
Re: "That&#= 39;s why I cannot understand the urgency to rise the maximum size."

This issue is urgent because the difference b= etween bitcoin being a success and it being forgotten hinges on it being &q= uot;better money" than other money. If people want a money that can pr= ocess lots and lots of transactions at low cost, they're going to get i= t so long as technology can give it to them. While it's not critical we= raise the block size this very moment since we're not hitting the capa= city wall right now, based on the way growth spikes in Bitcoin have occurre= d in the past we, may hit that capacity wall soon and suddenly. And the mom= ent we do, then Bitcoin may no longer be "better money" since the= re's a big opportunity for other money with higher throughput and lower= fees to take its place.

On Tue, Aug 11, 2015 at 2:45 PM, Jorge Tim=C3=B3n <j= timon@jtimon.cc> wrote:


On Aug 11, 2015 8:55 PM, "Michael Naber" <mickeybob@gmail.com> wrote:
>
> It generally doesn't matter that every node validate your coffee t= ransaction, and those transactions can and will probably be moved onto offc= hain solutions in order to avoid paying the cost of achieving global consen= sus. But you still don't get to set the cost of global consensus artifi= cially. Market forces will ensure that supply will meet demand there, so if= there is demand for access to global consensus, and technology exists to m= eet that demand at a cost of one cent per transaction -- or whatever the te= chnology-limited cost of global consensus happens to be -- then that's = what the market will supply.

Assuming we maintain any block size maximum consensus= rule, the market will adapt to whatever maximum size is imposed by the con= sensus rules.
For example, with the current demand and the current consensus block size m= aximum, the market has settled on a minimum fee of zero satoshis per transa= ction. That's why I cannot understand the urgency to rise the maximum s= ize.

In any case, yhe consensus maximum shouldn't be based on= current or projected demand, only on centralization concerns, which is wha= t the consensus rule serves for (to limit centralization).
For example, Gavin advocates for 20 MB because he is not worried about how = that could increase centralization because he believes it won't.
I can't agree with that because I believe 20 MB could make mining centr= alization (and centralization in general) much worse.

But if I have to chose between 2 "centralization safe&q= uot; sizes, sure, the bigger the better, why not.
In my opinion the main source of disagreement is that one: how the maximum = block size limits centralization.


--089e0122aec86f6032051d0fd40e--