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 4A53F905 for ; Fri, 10 Feb 2017 10:34:15 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-yb0-f193.google.com (mail-yb0-f193.google.com [209.85.213.193]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 05CDB90 for ; Fri, 10 Feb 2017 10:34:13 +0000 (UTC) Received: by mail-yb0-f193.google.com with SMTP id o65so1196402ybo.3 for ; Fri, 10 Feb 2017 02:34:13 -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=Pqq0/0IJvPQQGFmKXW8x5w5yiB7WrxRUzBhMEd0n7jM=; b=q8Sa8nqNAjg6OMzc88NJD1Itr7WCa+ehQuaYnZCERmHfH9BEgMPSv1m0JBUzd0brRZ EdG99YyNCoUGGLZdZMoCUpuLuPGp6XH55FjecFZQSW8m5qLfsHLCrzTxmkh0AdAtlyvz dgCXfLlqpylRR6Sc+tWJrCxaRJ2ONy2Q/AAZcQAsmB4OGKuEOHOsSQhu8dQhGZyFGVMh ZdDhcqcrYNU3vSxLHD/Zy62X/zZ1vsEqoGFVXG+DPc6r6yOgZ4x0ySsHbX0oTzzZeS// cvbJnEmqjtKLJBCm4N39SUOj8DpBn9vNjnlFqueJQ9jNeAlSUiT3K5wBRyXEzu5O7DXx cvIg== 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=Pqq0/0IJvPQQGFmKXW8x5w5yiB7WrxRUzBhMEd0n7jM=; b=IPITdiaXi0ufRzbFlKVhHACByp7EGFPuiy6HXjHNX3dvN4+a32IM35mYZiG4tqPny6 lzrmrC8ZOLYdmMtUDOatRv+PI82IUyGqtbBwRKGLOlkInLMLk7zfjguTbvZTW99mxQF8 QlTWLRahUggp2EM6GgW4jM2ozj0XooqXg2LCH9O+X62heqjK60nX9YzR2IuUXlR6E5cT NOjPHyPn4AypRdVD4AslxB+0RDtzSzBHn8d0184J6TZUw8SZi4zn4sr4239gCU2T6uem othrdcFtpkfUPAw8D0z17bN/e2vx8bgAR93qql7aOXooFfYT2VykvY2R1Bw7WXO/HZFO 4vDQ== X-Gm-Message-State: AMke39m0o2qXR2L0T0kFw1Gm5PPVqSe2/hhPRsdGdUGKT2DaxHIu+36aZWaS5CaOFzUFJbgK7ih0Rbtd2GAPBQ== X-Received: by 10.37.178.162 with SMTP id k34mr5815899ybj.21.1486722853178; Fri, 10 Feb 2017 02:34:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.52.10 with HTTP; Fri, 10 Feb 2017 02:33:52 -0800 (PST) In-Reply-To: References: <201702052302.29599.luke@dashjr.org> <201702061953.40774.luke@dashjr.org> From: Btc Drak Date: Fri, 10 Feb 2017 10:33:52 +0000 Message-ID: To: alp alp , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=f403045f3e368b15a205482aa3e6 X-Spam-Status: No, score=0.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FREEMAIL_REPLY, HK_RANDOM_ENVFROM, HK_RANDOM_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:34:51 +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: Fri, 10 Feb 2017 10:34:15 -0000 --f403045f3e368b15a205482aa3e6 Content-Type: text/plain; charset=UTF-8 Agreed, this thread is venturing somewhat out of scope for the list. Please can we redirect philosophical discussion to another forum/list such as bitcoin-discuss, which can be found at https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-discuss Repost of the bitcoin-dev posting guidelines are: - Posts must concern development of bitcoin protocol. - Posts should be technical or academic in nature. - Generally encouraged: patches, notification of pull requests, BIP proposals, academic paper announcements. And discussions that follow. - Generally discouraged: shower thoughts, wild speculation, jokes, +1s, non-technical bitcoin issues, rehashing settled topics without new data, moderation concerns. - Detailed patch discussion generally better on a GitHub PR. - Meta-discussion is better on bitcoin-discuss. On Wed, Feb 8, 2017 at 8:13 PM, alp alp via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > >Only the majority needs to consent, though what is considered a majority > varies depending on the context (95%, 75%, 51%). Nowhere does it say > "everyone needs to agree". > > There's a pretty huge gap between 90% and nearly 100%. 90% excluding 10% > only 7 times results in only 48% of the original base. > > >If a small dissenting minority can block all forward progress then > bitcoin is no longer interesting. > > Your definition of forward may be different than other users. > > >Is that really the bitcoin that you want to be a part of? > > Yes, I chose Bitcoin because it relies on a strictly held consensus > mechanism and not one that changes on the whims of the majority. We have > tens of dozens of political currencies for that. > > >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). > > The community has not agreed that it is needed at this time. Perhaps they > will change their mind at some point in the future. We have also learned a > great deal since the publication of the initial whitepaper, such as the > unstable state without a backlog or subsidy. Fortunately, participation in > this system is voluntary, and you are free to leave at any time. > > This seems to be venturing quite off topic, and perhaps would be better > suited for the bitcoin-discuss list. > > On Wed, Feb 8, 2017 at 1:56 PM, Andrew Johnson > wrote: > >> 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 >>>> >>>> >>>> >> >> > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --f403045f3e368b15a205482aa3e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Agreed, this thread is venturing somewhat out of scope for= the list. Please can we redirect philosophical discussion to another forum= /list such as bitcoin-discuss, which can be found at https://lists.linu= xfoundation.org/mailman/listinfo/bitcoin-discuss

Repost of the b= itcoin-dev posting guidelines are:

- Posts must concern development = of bitcoin protocol.=C2=A0
- Posts should be technical or academic in na= ture.=C2=A0
- Generally encouraged: patches, notification of pull reques= ts, BIP proposals, academic paper announcements. And discussions that follo= w.=C2=A0
- Generally discouraged: shower thoughts, wild speculation, jok= es, +1s, non-technical bitcoin issues, rehashing settled topics without new= data, moderation concerns.=C2=A0
- Detailed patch discussion generally = better on a GitHub PR.=C2=A0
- Meta-discussion is better on bitcoin-disc= uss.

On Wed,= Feb 8, 2017 at 8:13 PM, alp alp via bitcoin-dev <bitc= oin-dev@lists.linuxfoundation.org> wrote:
>Only the majority needs to consent, though what is consider= ed a majority varies depending on the context (95%, 75%, 51%). Nowhere does= it say "everyone needs to agree".

There's a pretty huge gap between 90% and nearly 100%. =C2=A090% ex= cluding 10% only 7 times results in only 48% of the original base.

>If a s= mall dissenting minority can block all forward progress then bitcoin is no = longer interesting.=C2=A0

Your definit= ion of forward may be different than other users.

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

Yes, I chose Bitcoin because it relies on a strictly held cons= ensus mechanism=C2=A0and not one that changes on the whims of the majority.= =C2=A0 We have tens of dozens of political currencies for that.

>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 certain= ly didn't.=C2=A0 It was never stated or implied that we could change th= e coin cap later(please cite if I'm mistaken).

The community has not agreed that it is needed at this time.= =C2=A0 Perhaps they will change their mind at some point in the future.=C2= =A0 We have also learned a great deal since the publication of the initial = whitepaper, such as the unstable state without a backlog or subsidy.=C2=A0 = Fortunately, participation in this system is voluntary, and you are free to= leave at any time.

<= /span>
This seems to be venturin= g quite off topic, and perhaps would be better suited for the bitcoin-discu= ss list.

On Wed, Feb 8, 2017 at 1:56 PM, Andrew Johnson <and= rew.johnson83@gmail.com> wrote:
If a small dissenting minority can block all fo= rward progress then bitcoin is no longer interesting.=C2=A0 What an incredi= bly simple attack vector...

No= need to break any cryptography, find a bug to exploit, build tens of milli= ons of dollars in mining hardware, spend lots of bitcoin on fees to flood t= he 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 b= locksize 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 certain= ly didn't.=C2=A0 It was never stated or implied that we could change th= e coin cap later(please cite if I'm mistaken).


On Feb 8, 2017 12:16 PM, "alp alp" <alp.bitcoin@gmail.com>= wrote:
Doing nothing is the rules = we all agreed to.=C2=A0 If those rules are to be changed,nearly everyone wi= ll need to consent.=C2=A0 The same rule applies to the cap, we all agreed t= o 21m, and if someone wants to change that, nearly everyone would need to a= gree.
=

On Feb 8, 201= 7 10:28 AM, "Andrew Johnson" <andrew.johnson83@gmail.com> wrote:
It is when you'r= e 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, 2= 017 9:57 AM, "alp alp" <alp.bitcoin@gmail.com> wrote:
10% is not a tiny m= inority.

On = Feb 8, 2017 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, &qu= ot;alp alp via bitcoin-dev" <bitcoin-dev@lists.linuxfoundation= .org> wrote:
10% say l= iterally never.=C2=A0 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 <luke@dashjr.org> wrote:
On M= onday, 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 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






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


--f403045f3e368b15a205482aa3e6--