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 33B1F409 for ; Sun, 16 Aug 2015 15:44:45 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 35226102 for ; Sun, 16 Aug 2015 15:44:44 +0000 (UTC) Received: by wicja10 with SMTP id ja10so53283282wic.1 for ; Sun, 16 Aug 2015 08:44:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=IJPibZLq3mUtqt8/3zeWDDOrRLsx7bhR3qmbpabMBsY=; b=Z74j2W48aCibAKo7VAHnuaIgLB/M+3JcDUZ/K8ROiOGZys2MGIhRVX2duqN/+LE+ET meitLDI5Bn4tz3Mw8oOgVinxCv5JWZh+UceVPodngsi6u5M/HcQcbsHt1ROb7r10JIvH mjF3s3HJLTVziV1ZjIfNbryDthvPXGuoQBtiC5sXHMq4UyxWTdaIkqbOmTPKlrrK4R/0 S2+2I0+NxLiSwZqgcCQwMZRrUCy10f/ehtoCOl7hRyRfn9nI8NNk45heGlxxAgP8QIV6 Sheml0uKR09DTDDDc49WhqpWnz72ne71UNlEQrqkKyd27stbOAyJ7Q2quuBDMuMptFfT QOzA== MIME-Version: 1.0 X-Received: by 10.180.231.40 with SMTP id td8mr26802589wic.9.1439739882805; Sun, 16 Aug 2015 08:44:42 -0700 (PDT) Sender: anthony.j.towns@gmail.com Received: by 10.28.176.69 with HTTP; Sun, 16 Aug 2015 08:44:42 -0700 (PDT) In-Reply-To: References: Date: Sun, 16 Aug 2015 17:44:42 +0200 X-Google-Sender-Auth: OwbIr4fMAaa4BPAJ94B-9GkLKrk Message-ID: From: Anthony Towns To: Mike Hearn Content-Type: multipart/alternative; boundary=001a1134cc5048a06e051d6f9097 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,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] Bitcoin XT 0.11A 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: Sun, 16 Aug 2015 15:44:45 -0000 --001a1134cc5048a06e051d6f9097 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 16 August 2015 at 15:49, Mike Hearn via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Sorry you feel that way. I devoted a big part of the article to trying to > fairly represent the top 3 arguments made, but ultimately I can't link to= a > clear statement of what Bitcoin Core thinks because there isn't one. Some > people think the block size should increase, but not now, or not by much. > Others think it should stay at 1mb forever, others think everyone should > migrate to Lightning, people who are actually *implementing* Lightning > think it's not a replacement for an increase ..... I think one or two > people even suggested shrinking the block size! > =E2=80=8BThat's been really unclear to me. Personally, I'd love to see a vo= te from the core and XT developers on: - what should the block size soft limit be in 12 months (min and max) - what should the block size hard limit be in 12 months (min and max) - at what rate should the hard limit grow over the next 10 years=E2=80=8B = (min and max) - what mechanism should be used to update the soft limit (manual code change, time based, blockchain history, something else) =E2=80=8B - what me=E2=80=8Bchanism should be used to update the hard limit (hard fork code change, time based, blockchain history, something else) Bonus: =E2=80=8B - what should the =E2=80=8Btransaction =E2=80=8B fee level be in 12 months (after the reward halves)?=E2=80=8B - what's a good measure of "(de)centralisation" and what value should everyone aim for in 12 months? As an interested newbie, I can't actually tell what most people think the answers to most of those questions are. FWIW, mine would be: - soft limit in 12 months: 1MB-4MB - hard limit in 12 months: 2MB-20MB - hard limit grows at 17-40% a year (and should be >4x average txn volume) - update the soft limit by code changes or blockchain history - update the hardlimit by (1) fee level, (2) miner vote, (3) hard coded time updates at a conservative (low) rate, (4) hard fork every couple of years - transaction fees should in 12months should be lower per kB than today's defaults, say 20%-50% of today's defaults in USD - number of bitcoin nodes, should be 20% higher in 12 months than it is no= w =E2=80=8BCheers, aj --=20 Anthony Towns --001a1134cc5048a06e051d6f9097 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 16 August 2015 at 15:49,= Mike Hearn via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
Sorry you feel that way. I devoted a big part of th= e article to trying to fairly represent the top 3 arguments made, but ultim= ately I can't link to a clear statement of what Bitcoin Core thinks bec= ause there isn't one. Some people think the block size should increase,= but not now, or not by much. Others think it should stay at 1mb forever, o= thers think everyone should migrate to Lightning, people who are actually <= i>implementing=C2=A0Lightning think it's not a replacement for an i= ncrease ..... I think one or two people even suggested shrinking the block = size!

=E2=80=8BThat's been really unclear= to me. Personally, I'd love to see a vote from the core and XT develop= ers on:
<= br>
=C2= =A0- what should the block size soft limit be in 12 months (min and max)
=C2=A0- wha= t should the block size hard limit be in 12 months (min and max)

=C2=A0- at what rate sh= ould the hard limit grow over the next 10 years=E2=80=8B (min and max)

=C2=A0- what mech= anism should be used to update the soft limit
=C2=A0 =C2=A0(manual code change, time= based, blockchain history, something else)
=E2=80=8B - what me=E2=80=8Bchanism shou= ld be used to update the hard limit
=C2=A0 =C2=A0(hard fork code change, time based,= blockchain history, something else)

Bonus:

=E2= =80=8B - what should the
=E2=80=8Btransaction =E2=80=8B
fee level be = in 12 months (after the reward halves)?=E2=80=8B
=C2=A0- what's a good measure = of "(de)centralisation" and what value should everyone aim for in= 12 months?

As an interested newbie, I can't actually tell what most peop= le think the answers to most of those questions are. FWIW, mine would be:

=
=C2=A0- soft l= imit in 12 months: 1MB-4MB
=C2=A0- hard limit in 12 months: 2MB-20MB
=C2=A0- hard limit grows= at 17-40% a year (and should be >4x average txn volume)
=C2=A0- update the soft = limit by code changes or blockchain history
=C2=A0- update the hardlimit by (1) fee = level, (2) miner vote, (3) hard coded time updates at a conservative (low) = rate, (4) hard fork every couple of years
=C2=A0- transaction fees should in 12month= s should be lower per kB than today's defaults, say 20%-50% of today= 9;s defaults in USD
=C2=A0- number of bitcoin nodes, should be 20% higher in 12 mont= hs than it is now

=E2=80=8BCheers,
aj
--
Anthony Towns <aj@erisian.com.au>
--001a1134cc5048a06e051d6f9097--