path: root/ff/38680332daf0dd69306f64922fd7c814205e5b

Return-Path: <truthcoin@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 7F4738E3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 21 Aug 2015 23:17:59 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qg0-f53.google.com (mail-qg0-f53.google.com
	[209.85.192.53])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3EEC9112
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 21 Aug 2015 23:17:58 +0000 (UTC)
Received: by qgeb6 with SMTP id b6so55735925qge.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 21 Aug 2015 16:17:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:to:references:from:message-id:date:user-agent:mime-version
	:in-reply-to:content-type:content-transfer-encoding;
	bh=EyogNzlENISmrBGDax3apABp4K8T6tsewp76dAa90VM=;
	b=GTA0ELDA60laS/qSd7o8jfvL3GOSqwkzNnVE/yj96uOozTMxi8PkhGwGmwc2VGKc2g
	QEfE+6DiVk2tYJD9GpDFsu2Oztk5uU+xkpPB36zKnBCcFvn0Qzs6HFHJLJS4eAyYekkZ
	I97PFWatKs/iCQLvhKftV9nqi4ZuhnTv/j66J6slOJfW9pbUeMIj1P0sZUEEPWejss9M
	GwVEdzNhUOcl7eADSWgeJxLmD5/prgKrMOQmEc26D/unF4AAWmdCKiQedsojSOIOKIpq
	Tvlqj2WPL4effp4ht0+dLyua2wYJL3FKVwWhqu1vLvS7JIrZiBBrPLhr4uh59371ZaYm
	olYQ==
X-Received: by 10.140.150.86 with SMTP id 83mr23987768qhw.79.1440199077487;
	Fri, 21 Aug 2015 16:17:57 -0700 (PDT)
Received: from [192.168.1.100] (ool-4575fa8d.dyn.optonline.net.
	[69.117.250.141]) by smtp.googlemail.com with ESMTPSA id
	b90sm5425668qga.48.2015.08.21.16.17.56
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 21 Aug 2015 16:17:56 -0700 (PDT)
To: Btc Drak <btcdrak@gmail.com>,
	Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
References: <CADJgMzvWKA79NHE2uFy1wb-zL3sjC5huspQcaDczxTqD_7gXOg@mail.gmail.com>
From: Paul Sztorc <truthcoin@gmail.com>
X-Enigmail-Draft-Status: N0010
Message-ID: <55D7B19F.6010806@gmail.com>
Date: Fri, 21 Aug 2015 19:17:51 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
	Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <CADJgMzvWKA79NHE2uFy1wb-zL3sjC5huspQcaDczxTqD_7gXOg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
	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
Subject: Re: [bitcoin-dev] Consensus based block size retargeting algorithm
 (draft)
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Aug 2015 23:17:59 -0000

You said:

> There is a perception that Bitcoin cannot easily respond to raising
the blocksize limit if popularity was to suddenly increase

=46rom this, my understanding is that you are operating on the principle
that "the optimum blocksize" is related to "popularity/use of Bitcoin".

It seems that others on this list instead feel that "the optimum
blocksize" is a function of "technical limitations (namely bandwidth)".
Do you acknowledge this as an irreconcilable difference in approach?

Also, I'm not sure, but your principle would seem to imply that
"outsourcing the decision to Miners" is superfluous. You are concerned
(according to you) with "not reacting to 'popularity' quickly enough",
and you are only against "predetermined increases" and "hashpower
influences" (according to you), so why not measure "popularity" directly
(by using "transaction volume" or "fees paid") and use that number to
set the blocksize?

--

However, thank you very much for actually stating a principle. Unless
one knows what a person's principle is, one *can't even check if* what
they are saying makes any sense (according to *them*), so my completely
sincere congratulations on an intelligible email.


On 8/21/2015 6:22 PM, Btc Drak via bitcoin-dev wrote:
> I wanted to offer a potential way to adjust the block size limit in a
> democratic way without making it easy to game. This is meant only as a
> starting point for a general idea. Thresholds and exact figures and
> the details of the algorithm are up for debate, and possibly some
> formula based determination.
>
> The living document is currently a gist available at
> https://gist.github.com/btcdrak/1c3a323100a912b605b5
>
>
> <pre>
>   BIP: XX
>   Title: Consensus based block size retargeting algorithm
>   Author: BtcDrak <btcdrak@gmail.com>
>   Status: Draft
>   Type: Standards Track
>   Created: 2015-08-21
> </pre>
>
> =3D=3DAbstract=3D=3D
>
> A method of altering the maximum allowed block size of the Bitcoin
> protocol using a consensus based approach.
>
> =3D=3DMotivation=3D=3D
>
> There is a perception that Bitcoin cannot easily respond to raising
> the blocksize limit if popularity was to suddenly increase due to a
> mass adoption curve, because co-ordinating a hard fork takes
> considerable time, and being unable to respond in a timely manner
> would irreparably harm the credibility of bitcoin.
>
> Additionally, predetermined block size increases are problematic
> because they attempt to predict the future, and if too large could
> have unintended consequences like damaging the possibility for a fee
> market to develop as block subsidy decreases substantially over the
> next 9 years; introducing or exacerbating mining attack vectors; or
> somehow affect the network in unknown or unpredicted ways. Since fixed
> changes are hard to deploy, the damage could be extensive.
>
> Dynamic block size adjustments also suffer from the potential to be
> gamed by the larger hash power.
>
>
> =3D=3DRationale=3D=3D
>
> By introducing a cost to increase the block size ensures the mining
> community will collude to increase it only when there is a clear
> necessity, and reduce it when it is unnecessary. Rogue miners cannot
> force their wishes so easily because not only will they have to pay
> extra a difficulty target, then can be downvoted at no cost by the
> objecting hash power.
>
>
> =3D=3DSpecification=3D=3D
>
> The initial "base block size limit" shall be 1MB.
>
> Miners can vote for a block size increase by signalling the proposed
> percentage increase of the "base block size limit" in the coinbase
> field. For the vote to be considered valid the block they mine must
> meets a difficulty target which is proportionally larger than the
> standard difficulty target based on the percentage increase they voted
> for. If a miner does not vote, or the vote is invalid, it shall be
> counted as a vote for no change.
>
> Miners may vote the size down by signalling in the coinbase field
> without paying a difficulty penalty.
>
> Every 2016 blocks, the maximum allowed block size will be recalculated
> by the average of all votes in the last 2016 blocks, i.e. sum each
> vote from each block and divide by 2016 then multiply by the base
> block size limit. This will redefine the base block size limit for the
> next 2016 blocks.
>
> Blocks that are larger than the calculated base block size limit are
> invalid and MUST be rejected.
>
> The maximum change up or down each retargeting period shall be limited
> to 10% of the base block size limit.
>
> The maximum block size may not increase above 8MB.
>
> Votes shall be cast by adding the following human readable multiplier
> to the coinbase string =E2=80=9C/BXn.nnn/=E2=80=9D where valid votes wo=
uld exist
> between the ranges =E2=80=9C/BX0.900/=E2=80=9D (10% decrease) and =E2=80=
=9C/BX1.100/=E2=80=9D (10%
> increase). =E2=80=9C/BX1.000/=E2=80=9D would be a vote for no change. I=
nvalid votes
> will be counted as a vote for no change: =E2=80=9C/BX1.000/=E2=80=9D.
>
>
> =3D=3DAcknowledgements=3D=3D
>
> This proposal is based on ideas and concepts derived from the writings
> of Meni Rosenfeld and Gregory Maxwell.
>
>
> =3D=3DCopyright=3D=3D
>
> This work is placed in the public domain.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev