Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 642D1CD4 for ; Wed, 8 Feb 2017 19:56:21 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f48.google.com (mail-vk0-f48.google.com [209.85.213.48]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 78F0D247 for ; Wed, 8 Feb 2017 19:56:20 +0000 (UTC) Received: by mail-vk0-f48.google.com with SMTP id x75so108823971vke.2 for ; Wed, 08 Feb 2017 11:56:20 -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 :cc; bh=gz8pcR25vzBz21zA2XmNQSrCavRt6QD8AEEKy+auesQ=; b=vhenIgwo8AQ/oCicJSjuG/9ULkVgT2MngUhCowIevwiCr1+FxvUdiyaIu+MwbaDh7W vFBc7dvToKEj8gb+Tp/fabpBr64dFsAF4ZKE5pxYdx+i4zHwkW+jPrC279898nxC5+9R axz90wsP6tmjmWZ3+Dfx2WT3XrnW/K5jGuaEmqYISL6wiSjho8Eu2m1Lxzxcpsxx8Qme iD1gTU162AQID/7diV3ghpyFeFvTKDTX7NGEQlqBTuGrrHnmU3nWTNrHnEc7Nf5e6Dz1 flSIukPmSkokuO+mlBEw7bTt/ssglUrAFzyRd1a2o2R0PzE3xRFvmMl1+iCDfhfH44E6 rmQg== 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:cc; bh=gz8pcR25vzBz21zA2XmNQSrCavRt6QD8AEEKy+auesQ=; b=rYSvhiPMP0B2mxQ4x9jCOkaEyqTCZizE8EdGcNREmEdYf5jrssd2TiTix2uHH98Tku YBhJbGi5lffwSJJ8acQd/8aqhL0o1jqMefvdi+PaJ5R4XeBz9HrKSayijdhEbNBH29oB Ib1TKAwrBX39vjTS+Kdk0Ky7zj+KmY0DY0zZu1x4kKA6tASeConZEUdlZ7qgcdB+wo61 nCGGuEZW8aNBL0x6RDE/sBvZc38FdiZ+OK/buZxl97hxN6VJA2GyzJNGW98ymO5BWB4t Kk0QtqxSCCS+DEdmE7o4P21EDRvHkkke5PteFXts297Yhb+T5ceD7I7KGm/gicVrxwyP 3s5g== X-Gm-Message-State: AMke39mWJtHlRyeJil+sfmbCXm8MjEXPwnxB9IGaAQhJcIasEDXzmKWzw/AJG5X4ma/79s4/jpAPMPU2jsUZeg== X-Received: by 10.31.225.71 with SMTP id y68mr3560230vkg.166.1486583779569; Wed, 08 Feb 2017 11:56:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.152.19 with HTTP; Wed, 8 Feb 2017 11:56:19 -0800 (PST) Received: by 10.103.152.19 with HTTP; Wed, 8 Feb 2017 11:56:19 -0800 (PST) In-Reply-To: References: <201702052302.29599.luke@dashjr.org> <201702061953.40774.luke@dashjr.org> From: Andrew Johnson Date: Wed, 8 Feb 2017 13:56:19 -0600 Message-ID: To: alp alp Content-Type: multipart/alternative; boundary=001a114e00be1c475505480a4238 X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Fri, 10 Feb 2017 10:23:41 +0000 Cc: Bitcoin Dev 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 19:56:21 -0000 --001a114e00be1c475505480a4238 Content-Type: text/plain; charset=UTF-8 If a small dissenting minority can block all forward progress then bitcoin is no longer interesting. What an incredibly simple attack vector... No need to break any cryptography, find a bug to exploit, build tens of millions of dollars in mining hardware, spend lots of bitcoin on fees to flood the network, or be clever or expend any valuable resources in any way, shape, or form. Just convince(or pay, if you do want to expend some resources) a few people(or make up a few online personas) to staunchly refuse to accept anything at all and the entire system is stuck in 2013(when we first started widely discussing a blocksize increase seriously). Is that really the bitcoin that you want to be a part of? When the 1MB cap was implemented it was stated specifically that we could increase it when we needed it. The white paper even talks about scaling to huge capacity. Not sure where you got the idea that we all agreed to stay at 1MB forever, I certainly didn't. It was never stated or implied that we could change the coin cap later(please cite if I'm mistaken). On Feb 8, 2017 12:16 PM, "alp alp" wrote: Doing nothing is the rules we all agreed to. If those rules are to be changed,nearly everyone will need to consent. The same rule applies to the cap, we all agreed to 21m, and if someone wants to change that, nearly everyone would need to agree. On Feb 8, 2017 10:28 AM, "Andrew Johnson" wrote: It is when you're talking about making a choice and 6.3x more people prefer something else. Doing nothing is a choice as well. Put another way, if 10% supported increasing the 21M coin cap and 63% were against, would you seriously consider doing it? On Feb 8, 2017 9:57 AM, "alp alp" wrote: > 10% is not a tiny minority. > > On Feb 8, 2017 9:51 AM, "Andrew Johnson" > wrote: > >> You're never going to reach 100% agreement, and stifling the network >> literally forever to please a tiny minority is daft. >> >> On Feb 8, 2017 8:52 AM, "alp alp via bitcoin-dev" < >> bitcoin-dev@lists.linuxfoundation.org> wrote: >> >> 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 >>> >>> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> >> --001a114e00be1c475505480a4238 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If a small dissenting minority can block all forward= progress then bitcoin is no longer interesting.=C2=A0 What an incredibly s= imple attack vector...

No need= to break any cryptography, find a bug to exploit, build tens of millions o= f dollars in mining hardware, spend lots of bitcoin on fees to flood the ne= twork, or be clever or expend any valuable resources in any way, shape, or = form.

Just convince(or p= ay, if you do want to expend some resources) a few people(or make up a few = online personas) to staunchly refuse to accept anything at all and the enti= re system is stuck in 2013(when we first started widely discussing a blocks= ize increase seriously).

Is that really the bitcoin that you want to be a part of?

When the 1MB cap was implemented it was = stated specifically that we could increase it when we needed it.=C2=A0 The = white paper even talks about scaling to huge capacity.=C2=A0 Not sure where= you got the idea that we all agreed to stay at 1MB forever, I certainly di= dn't.=C2=A0 It was never stated or implied that we could change the coi= n cap later(please cite if I'm mistaken).


On Feb 8, 2017 12:16 PM, "alp al= p" <alp.bitcoin@gmail.com<= /a>> wrote:
Doing nothing is the rules we all agreed to.=C2=A0 If those rul= es are to be changed,nearly everyone will need to consent.=C2=A0 The same r= ule applies to the cap, we all agreed to 21m, and if someone wants to chang= e that, nearly everyone would need to agree.

=

On Feb 8, 2017 10= :28 AM, "Andrew Johnson" <andrew.johnson83@gmail.com> wrote:
It is when you're talking about making a choice and 6.3x more= people prefer something else. Doing nothing is a choice as well.

Put another way, if 10% supported inc= reasing the 21M coin cap and 63% were against, would you seriously consider= doing it?

On Feb 8, 2017 9:57 AM= , "alp alp" <alp.bitcoin@gmail.com> wrote:
10% is not a tiny minority.<= /div>

On Feb 8, 20= 17 9:51 AM, "Andrew Johnson" <andrew.johnson83@gmail.com> wrote:
You're never going to reach 100% agreement, and stifling the network = literally forever to please a tiny minority is daft.

On Feb 8, 2017 8:52 AM, "alp al= p via bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org&= gt; wrote:
10% say literally never.=C2=A0 That seems like a significant = disenfranchisement and lack of consensus.
<= br>
On Mon= , Feb 6, 2017 at 2:25 PM, t. khan via bitcoin-dev <bit= coin-dev@lists.linuxfoundation.org> wrote:
On Mon, Feb 6, 2017 at 2:53 PM, Luke Dashjr <luke@dashjr.org> wrote:
On Monday, February 06, 2017 6:19:4= 3 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 tha= t? 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 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



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




--001a114e00be1c475505480a4238--