Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 35243D46 for ; Fri, 28 Aug 2015 23:35:45 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f178.google.com (mail-io0-f178.google.com [209.85.223.178]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6988D231 for ; Fri, 28 Aug 2015 23:35:44 +0000 (UTC) Received: by ioed140 with SMTP id d140so21952690ioe.2 for ; Fri, 28 Aug 2015 16:35:43 -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=0YB1KwFrkvm1g7xY+l51eFYy1b1DSk9G5m5kMcsmIfw=; b=fpCXryvbC6SSaJhxb628TWtnm7ZcjdcPx0a/cUo0A60zLnf6xZ0+Xs30ngQckbtXaF IMUS44Ci0HLLgskdn0vZDvUZw5NKpcvBXUUrkPUsRaOx9Gd7F6KO+6mbxnJ3V79IQrQM jndzj2ACebLTHFMwByAUeNYWU+3tA3rExqE13+49ShY5ytSYFMIugkCJD27XacHF+wdt KbJ+YGCnpMmumGBg0uUP5DbwCQ41GXnHmpQg64ZeKqnGB3M3bFDgqmxuLreVc5vf9ney lLLkmBhLCcvNRUb/4W3cM2Qmce7QoylaEUoVKqOOkiwsCqp+18V3jojIvkS9hb7baqYH 0MpQ== MIME-Version: 1.0 X-Received: by 10.107.137.208 with SMTP id t77mr15672007ioi.2.1440804943815; Fri, 28 Aug 2015 16:35:43 -0700 (PDT) Received: by 10.36.144.196 with HTTP; Fri, 28 Aug 2015 16:35:43 -0700 (PDT) Received: by 10.36.144.196 with HTTP; Fri, 28 Aug 2015 16:35:43 -0700 (PDT) In-Reply-To: References: <2081355.cHxjDEpgpW@crushinator> Date: Fri, 28 Aug 2015 19:35:43 -0400 Message-ID: From: Chris Pacia To: Gavin Content-Type: multipart/alternative; boundary=001a113ed538de0f39051e678a33 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@lists.linuxfoundation.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 23:35:45 -0000 --001a113ed538de0f39051e678a33 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable When discussing this with Matt Whitlock earlier we basically concluded the block size will never increase under this proposal do to a collective action problem. If a miner votes for an increase and nobody else does, the blocksize will not increase yet he will still have to pay the difficulty penalty. It may be in everyone's collective interest to raise the block size but not their individual interest. On Aug 28, 2015 6:24 PM, "Gavin via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > With this proposal, how much would it cost a miner to include an 'extra' > 500-byte transaction if the average block size is 900K and it costs the > miner 20BTC in electricity/capital/etc to mine a block? > > If my understanding of the proposal is correct, it is: > > 500/900000 * 20 =3D 0.11111 BTC > > ... Or $2.50 at today's exchange rate. > > That seems excessive. > > -- > Gavin Andresen > > > > On Aug 28, 2015, at 5:15 PM, Matt Whitlock via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > > This is the best proposal I've seen yet. Allow me to summarize: > > > > =E2=80=A2 It addresses the problem, in Jeff Garzik's BIP 100, of miners= selling > their block-size votes. > > =E2=80=A2 It addresses the problem, in Gavin Andresen's BIP 101, of bli= ndly > trying to predict future market needs versus future technological > capacities. > > =E2=80=A2 It avoids a large step discontinuity in the block-size limit = by > starting with a 1-MB limit. > > =E2=80=A2 It throttles changes to =C2=B110% every 2016 blocks. > > =E2=80=A2 It imposes a tangible cost (higher difficulty) on miners who = vote to > raise the block-size limit. > > =E2=80=A2 It avoids incentivizing miners to vote to lower the block-siz= e limit. > > > > However, this proposal currently fails to answer a very important > question: > > > > =E2=80=A2 What is the mechanism for activation of the new consensus rul= e? It is > when a certain percentage of the blocks mined in a 2016-block retargeting > period contain valid block-size votes? > > > > > > https://github.com/btcdrak/bips/blob/bip-cbbsra/bip-cbbrsa.mediawiki > > > > > >> On Friday, 28 August 2015, at 9:28 pm, Btc Drak via bitcoin-dev wrote: > >> Pull request: https://github.com/bitcoin/bips/pull/187 > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --001a113ed538de0f39051e678a33 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

When discussing this with Matt Whitlock earlier we basically= concluded the block size will never increase under this proposal do to a c= ollective action problem. If a miner votes for an increase and nobody else = does, the blocksize will not increase yet he will still have to pay the dif= ficulty penalty.

It may be in everyone's collective interest to raise the= block size but not their individual interest.

On Aug 28, 2015 6:24 PM, "Gavin via bitcoin= -dev" <bit= coin-dev@lists.linuxfoundation.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">With this proposal, how much would it cost a = miner to include an 'extra' 500-byte transaction if the average blo= ck size is 900K and it costs the miner 20BTC in electricity/capital/etc to = mine a block?

If my understanding of the proposal is correct, it is:

500/900000 * 20 =3D 0.11111 BTC

... Or $2.50 at today's exchange rate.

That seems excessive.

--
Gavin Andresen


> On Aug 28, 2015, at 5:15 PM, Matt Whitlock via bitcoin-dev <bitcoin-dev@lists.linuxfo= undation.org> wrote:
>
> This is the best proposal I've seen yet. Allow me to summarize: >
> =E2=80=A2 It addresses the problem, in Jeff Garzik's BIP 100, of m= iners selling their block-size votes.
> =E2=80=A2 It addresses the problem, in Gavin Andresen's BIP 101, o= f blindly trying to predict future market needs versus future technological= capacities.
> =E2=80=A2 It avoids a large step discontinuity in the block-size limit= by starting with a 1-MB limit.
> =E2=80=A2 It throttles changes to =C2=B110% every 2016 blocks.
> =E2=80=A2 It imposes a tangible cost (higher difficulty) on miners who= vote to raise the block-size limit.
> =E2=80=A2 It avoids incentivizing miners to vote to lower the block-si= ze limit.
>
> However, this proposal currently fails to answer a very important ques= tion:
>
> =E2=80=A2 What is the mechanism for activation of the new consensus ru= le? It is when a certain percentage of the blocks mined in a 2016-block ret= argeting period contain valid block-size votes?
>
>
> https://github.com/btcdrak/= bips/blob/bip-cbbsra/bip-cbbrsa.mediawiki
>
>
>> On Friday, 28 August 2015, at 9:28 pm, Btc Drak via bitcoin-dev wr= ote:
>> Pull request: https://github.com/bitcoin/bips/pull/= 187
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@l= ists.linuxfoundation.org
> https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--001a113ed538de0f39051e678a33--