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 2F4EAB4A for ; Wed, 8 Feb 2017 14:44:55 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lf0-f44.google.com (mail-lf0-f44.google.com [209.85.215.44]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 64A72AC for ; Wed, 8 Feb 2017 14:44:54 +0000 (UTC) Received: by mail-lf0-f44.google.com with SMTP id n124so83164050lfd.2 for ; Wed, 08 Feb 2017 06:44:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=L6Ir5eb/m717J4ljXAaplCnYr7VrMR0DL6GwQc4lY+s=; b=d98fNdW2mtGJJmqM4kxi6GjZ5QHZ12+05uJSjVUGsqrk1uxP3XyyEpyx3TNPiVLbfr HrmOSRUjpBs7SG45BZY9cMUHGH30ElKkocNGjTIktVKTX3wZJEqDhwjl5nXwBOkoOqfo hQZ+ibulrsrqFWDrpWKFQIhdJTb4ACh04ytw+PSaZyisBPHs6aLdRbHz1J6YXTAXuk/E 1zwwngJR75usBQTrgeo8yKb9+3Xf+Bmxtl3S0jRHN6ggrMNAfX4vBKjU5YhtX6RFp0I/ gy8Th69K3epWJ48dkCslSZ4ZreCmJN9MHGwpqjOvfU5wDFKYhCvZi4ZJO/3mFCR9vw7z mMVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=L6Ir5eb/m717J4ljXAaplCnYr7VrMR0DL6GwQc4lY+s=; b=cPheEt/ixxh3WElfcYkmK2I1+0w5nol+xQKd65fyXy0bGOH4AqTLbjXYakhDHNNRlR 08fvkElO177jcniFgqkJWfE/3d2Ane0sfmbldWTv65m2QPqR/F5PwiKrzJ6cmYjFRegY 3KQDwJ+OI2L6va7LY8bk2WQKwVYoES87Bc/lEWKOm6RaZETZvSsSArze2R5Ke5ske9/7 Vr5+H8J/Qr8zzZ6zpSILi42HU05HmRz1k8NliS7rlEZZJ7InuUBHhCts41M1tMX3gKao Q0Pjyth2u1tkra6k1gLPQp8mlRFACvZTgqLND6R/C24K6biaIpDv436Kj92JF3vQZvtr ftRw== X-Gm-Message-State: AIkVDXLY8zQ5FoG/qiPL+LM9pwueNfI4CTUlLRl7ZVq55jNNRmrk82gEqm0BWXIes0MoMO7/JTpUUYeV1cMlOA== X-Received: by 10.25.196.136 with SMTP id u130mr6796313lff.37.1486565092815; Wed, 08 Feb 2017 06:44:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.21.92 with HTTP; Wed, 8 Feb 2017 06:44:52 -0800 (PST) In-Reply-To: References: <201702052302.29599.luke@dashjr.org> <201702061953.40774.luke@dashjr.org> From: alp alp Date: Wed, 8 Feb 2017 08:44:52 -0600 Message-ID: To: "t. khan" , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=001a114b1a164af96e054805e8c2 X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Wed, 08 Feb 2017 14:52:13 +0000 Subject: Re: [bitcoin-dev] A Modified Version of Luke-jr's Block Size BIP X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 14:44:55 -0000 --001a114b1a164af96e054805e8c2 Content-Type: text/plain; charset=UTF-8 10% say literally never. That seems like a significant disenfranchisement and lack of consensus. On Mon, Feb 6, 2017 at 2:25 PM, t. khan via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Mon, Feb 6, 2017 at 2:53 PM, Luke Dashjr wrote: > >> On Monday, February 06, 2017 6:19:43 PM you wrote: >> > >My BIP draft didn't make progress because the community opposes any >> block >> > >size increase hardfork ever. >> > >> > Luke, how do you know the community opposes that? Specifically, how did >> you >> > come to this conclusion? >> >> http://www.strawpoll.me/12228388/r > > > That poll shows 63% of votes want a larger than 1 MB block by this summer. > How do you go from that to "the community opposes any block increase ever"? > It shows the exact opposite of that. > > >> > >Your version doesn't address the current block size >> > >issues (ie, the blocks being too large). >> > >> > Why do you think blocks are "too large"? Please cite some evidence. I've >> > asked this before and you ignored it, but an answer would be helpful to >> the >> > discussion. >> >> Full node count is far below the safe minimum of 85% of economic activity. >> > > Is this causing a problem now? If so, what? > > >> Typically reasons given for people not using full nodes themselves come >> down >> to the high resource requirements caused by the block size. > > > The reason people stop running nodes is because there's no incentive to > counteract the resource costs. Attempting to solve this by making blocks > *smaller* is like curing a disease by killing the patient. (Incentivizing > full node operation would fix that problem.) > > - t.k. > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --001a114b1a164af96e054805e8c2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
10% say literally never.=C2=A0 That seems like a significa= nt disenfranchisement and lack of consensus.

On Mon, Feb 6, 2017 at 2:25 PM, t. khan vi= a bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
On Monday, February 06, 2017 6:19:43 PM you wrote:
> >My BIP draft didn't make progress because the community oppose= s any block
> >size increase hardfork ever.
>
= > Luke, how do you know the community opposes that? Specifically, how di= d you
> come to this conclusion?

http://www.strawpoll.me/12228388/r

That poll shows 63% of votes want a larger than 1 MB blo= ck by this summer. How do you go from that to "the community opposes a= ny block increase ever"? It shows the exact opposite of that.
=C2= =A0
> >Your version doesn't address the current block size
> >issues (ie, the blocks being too large).
>
> Why do you think blocks are "too large"? Please cite some ev= idence. I've
> asked this before and you ignored it, but an answer would be helpful t= o the
> discussion.

Full node count is far below the safe minimum of 85% of econo= mic activity.

Is this causing a problem= now? If so, what?
=C2=A0
Typically reasons given for people not using full nodes themselves come dow= n
to the high resource requirements caused by the block size.

The reason people stop running nodes is because there'= s no incentive to counteract the resource costs. Attempting to solve this b= y making blocks *smaller* is like curing a disease by killing the patient. = (Incentivizing full node operation would fix that problem.)
<= br>
- t.k.


_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev


--001a114b1a164af96e054805e8c2--