From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 872EB323 for ; Sat, 1 Aug 2015 21:05:11 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ig0-f170.google.com (mail-ig0-f170.google.com [209.85.213.170]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F2813EE for ; Sat, 1 Aug 2015 21:05:10 +0000 (UTC) Received: by igbij6 with SMTP id ij6so35124820igb.1 for ; Sat, 01 Aug 2015 14:05:10 -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=X5NH1uMBHJWTX8fVB/kGhzt+ZB3xL5GBMirAfT24igc=; b=hxcLe0r/IeDmPpR1m2qAoqOdGq+V6bzPO5btDbuiKksw4N0FksbHrW7vsjc5GAnTcA Bh/7OoYvK/XYcfeejcgz2D9LXGpVC8czEktArEwKhwUGeP8nyNjLQCxACIVyqLltGk5w w0nYclyH47eMTTSCvxypIhRRG3ID1pHbb5OHRN2nvDiHw5Zn5ujNF7niN3n0bHZti9CE EWQnBBoeAO4cYFo+vY/U+KuQ7TM35VH7nzRQvWFhQcHJKmMrtgVn5BzkX5WKAM2Hw2nf Kqkq6O74bmraWEU05w4H2YpVensLmOeitDYHGq32SM2KfVSGruR6JURoBUlbpMtl+9lY P7rw== MIME-Version: 1.0 X-Received: by 10.50.93.69 with SMTP id cs5mr14936088igb.4.1438463110497; Sat, 01 Aug 2015 14:05:10 -0700 (PDT) Received: by 10.36.77.201 with HTTP; Sat, 1 Aug 2015 14:05:10 -0700 (PDT) In-Reply-To: <55BD2A7C.9060504@juno.com> References: <1B7F00D3-41AE-44BF-818D-EC4EF279DC11@gmail.com> <25FD9AAD-99F5-4322-AF34-243F75AE82C4@gmail.com> <4608887.aSM42bDkNk@coldstorage> <55BD2A7C.9060504@juno.com> Date: Sat, 1 Aug 2015 23:05:10 +0200 Message-ID: From: Pieter Wuille To: "John T. Winslow" Content-Type: multipart/alternative; boundary=089e01537ed8b94d4d051c464aa1 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] Why Satoshi's temporary anti-spam measure isn't temporary 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: Sat, 01 Aug 2015 21:05:11 -0000 --089e01537ed8b94d4d051c464aa1 Content-Type: text/plain; charset=UTF-8 On Sat, Aug 1, 2015 at 10:22 PM, John T. Winslow via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Regarding the block size increase, at least conceptually it seems to me > there should be an easy solution. If we look at what works well with > bitcoin, for example the block reward halving and difficulty regimes which > due to their step function nature both contribute to the stability and > predictability of the bitcoin universe while still allowing for the > necessary dynamic adjustments. It seems to me there should be a > corresponding and equally simple solution for the maximum block size. > > I've never quite understood the supposed rationale behind the proposals > for a new static maximum of 20 MB or 8 MB or 2 MB other than it would be > trivial to implement. Why not come up with an equally simple, predictable > dynamic function consistent with what is already proven to work in the > bitcoin universe that would both preserve the scarcity of transaction > capacity to encourage a fee market but also allow for more transactions > when needed. > I disagree with the notion of "needed". The blockchain provides utility at every size, and perhaps more at some sizes than at other sizes, but any finite size will permit some use cases and not others. This is already the case and will remain the case. I think the "demand for payments" should be considered infinite, and some of them will fit on a block chain and pay a fee for it, and others will need to rely on more efficient, cheaper, but higher trust systems. You can't use observed usage as a metric for demand without fixing the cost. I think available space should grow with technology, to keep the relative costs to the ecosystem for maintaining a decentralized system constant. That may or may not lead to a fee market, but I don't think the fee market is a goal - only a healthy outcome. The goal is an ecosystem that accepts that the limit to scalability is set by the requirements of a decentralized system, and its demand - and certainly not perceived demand at potentially near-zero fee/cost - can't change that. > For example how about something like once every month at month-end, take > the 6-month average non-zero transaction fee block size and multiply by 1.5? > > That's trivially gamable by miners, by filling the blocks with their own transactions. -- Pieter --089e01537ed8b94d4d051c464aa1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Aug 1, 2015 at 10:22 PM, John T. Winslow via bitco= in-dev <bitcoin-dev@lists.linuxfoundation.org><= /span> wrote:
=20 =20 =20
Regarding the block size increase, at least conceptually it seems to me there should be an easy solution. If we look at what works well with bitcoin, for example the block reward halving and difficulty regimes which due to their step function nature both contribute to the stability and predictability of the bitcoin universe while still allowing for the necessary dynamic adjustments. It seems to me there should be a corresponding and equally simple solution for the maximum block size.

I've never quite understood the supposed rationale behind the proposals for a new static maximum of 20 MB or 8 MB or 2 MB other than it would be trivial to implement. Why not come up with an equally simple, predictable dynamic function consistent with what is already proven to work in the bitcoin universe that would both preserve the scarcity of transaction capacity to encourage a fee market but also allow for more transactions when needed.

I disagree with the notion of "nee= ded". The blockchain provides utility at every size, and perhaps more = at some sizes than at other sizes, but any finite size will permit some use= cases and not others. This is already the case and will remain the case. I= think the "demand for payments" should be considered infinite, a= nd some of them will fit on a block chain and pay a fee for it, and others = will need to rely on more efficient, cheaper, but higher trust systems. You= can't use observed usage as a metric for demand without fixing the cos= t.

I think available space should grow with technology, t= o keep the relative costs to the ecosystem for maintaining a decentralized = system constant. That may or may not lead to a fee market, but I don't = think the fee market is a goal - only a healthy outcome. The goal is an eco= system that accepts that the limit to scalability is set by the requirement= s of a decentralized system, and its demand - and certainly not perceived d= emand at potentially near-zero fee/cost - can't change that.


For example how about something like once every month at month-end, take the 6-month average non-zero transaction fee block size and multiply by 1.5?


That's trivially= gamable by miners, by filling the blocks with their own transactions.
<= br>--
Pieter

--089e01537ed8b94d4d051c464aa1--