Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 776F083D for ; Tue, 11 Aug 2015 19:45:37 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D0E9017B for ; Tue, 11 Aug 2015 19:45:36 +0000 (UTC) Received: by wicne3 with SMTP id ne3so74422579wic.0 for ; Tue, 11 Aug 2015 12:45:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=CpDCXaByHxZDAZ2le0hmtV7mFzARnKqP0Y6TcURSG9g=; b=lUggw1qbfUVl9H938zx0Ee54twhX+Gu+8JwUX2ljYGYhoVZRgx0coIK6Q2wpFFl7/y pTGm51wioQTTWCP584Xxk3gB3svA+a1/Giu026NXhQS2t6Nqh4zqhxErTSEfS+Zjjda2 OtYEi/Pqp/YcP6ATwrTOdpqvRQLIvfRgdocrteQBARGfFUlWNcXW0q2ernKhYo3DIueN 7FjPjc8xdL+crrO8t4ZxZFFALAG01FPBqc5w16JITFGFz5hkUnbFQqmR/en8gkS/oUEO TIMO4/HdsDgBWMjwkZ3leiR96Lz8sWCDIJvIE3SrmyYo9xhx61WxLutt8RqljddWPaY6 tK5A== X-Gm-Message-State: ALoCoQnKSLvUp++dw33wFWnjQNIXuYoZPH3q5mVN+0MVr+lGuLHCWx0d+mVwa5jTRKx8ZYPj3qLV MIME-Version: 1.0 X-Received: by 10.180.37.74 with SMTP id w10mr37159855wij.92.1439322335590; Tue, 11 Aug 2015 12:45:35 -0700 (PDT) Received: by 10.194.31.230 with HTTP; Tue, 11 Aug 2015 12:45:35 -0700 (PDT) Received: by 10.194.31.230 with HTTP; Tue, 11 Aug 2015 12:45:35 -0700 (PDT) In-Reply-To: References: <8181630.GdAj0CPZYc@coldstorage> Date: Tue, 11 Aug 2015 21:45:35 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Michael Naber Content-Type: multipart/alternative; boundary=e89a8f64720f87f201051d0e5860 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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 19:45:37 -0000 --e89a8f64720f87f201051d0e5860 Content-Type: text/plain; charset=UTF-8 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 there, so if there is demand for access to global consensus, and technology exists 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 maximum 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 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 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 maximum block size limits centralization. --e89a8f64720f87f201051d0e5860 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


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 consensus = 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.

--e89a8f64720f87f201051d0e5860--