Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 3EC9FB76 for ; Wed, 8 Feb 2017 20:13:22 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lf0-f65.google.com (mail-lf0-f65.google.com [209.85.215.65]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D42A1188 for ; Wed, 8 Feb 2017 20:13:20 +0000 (UTC) Received: by mail-lf0-f65.google.com with SMTP id v186so10310422lfa.2 for ; Wed, 08 Feb 2017 12:13: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=OB4EC9J1pQumbFzEZGDgFqF/Sj/rFoleqWVQe3Fk+58=; b=ajqAMKwB0LKJfobYI0pccLwlygv+kf0AZ765B/a2bYS6K4BAzxB9sHnQIZlAXJNuOE AHH3RV5cvExooXjsclFrz+DbHKhaxl/4lUxc0EBxtbQEBi5DQP0UNk378Me6fvHk9RYk 93dTfS0ZRJxdJr5DXXhHzawAofKjMBNbDhVrSzRpjnF+zBwpygsKpLwVJxbnOEH6j8xN akRALCwmXPwUt8zevp1lU5+tG76bOekfez4dUQfA8ShuenbGQV5bfg3999pUDrbqjW2b 4wf07mDaGSgmUW3aZMRQKI3GKc02Y7rM+4Qd5U9tI0kOUf6AJvC5V7CPoR9g5YI66v60 557w== 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=OB4EC9J1pQumbFzEZGDgFqF/Sj/rFoleqWVQe3Fk+58=; b=I0c4LkEopmGZjhXdUaq3PkxmMezrdbxWSSKZ5F2eB+L8CJ9AaPJ9vppzPDMTMdyqfn cNiEoa1SLmC7MhZbZ64lAoyQuGdx4AvW21/q6WSET+JrV+UJyKYTYcH4bdCSIt7L+cR8 Y/2m0NEDC/yeQdXEjoKSFfubfVsU0zQEkhNqxNFL4e5/bNpUGjkNKozWVLN3eAp2v+LX q1EpqSpj51+BlbymnqthKcOAR8Ixlgzym9d34hlR6LVi+tCLO9g4eDz8a4Jit0uy/AuX nEyAMLsqYPo0aip3AXepb4i8/7SngsVCQWAAkVJpqU5wc2DxkMkLMcnoUpdYwMeVSHj2 EgcQ== X-Gm-Message-State: AMke39mvUnXizqOSjLXRQPu+1NIE2oYo6Pf05k8MRbqc8CtSa/IHmYgCpM/cKB22YW6oYJDke5G9uGOb/ih8Iw== X-Received: by 10.25.202.83 with SMTP id h19mr8356304lfj.33.1486584799200; Wed, 08 Feb 2017 12:13:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.21.92 with HTTP; Wed, 8 Feb 2017 12:13:18 -0800 (PST) In-Reply-To: References: <201702052302.29599.luke@dashjr.org> <201702061953.40774.luke@dashjr.org> From: alp alp Date: Wed, 8 Feb 2017 14:13:18 -0600 Message-ID: To: Andrew Johnson Content-Type: multipart/alternative; boundary=f403045e9f50e28a9605480a7e5e X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, 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:42 +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 20:13:22 -0000 --f403045e9f50e28a9605480a7e5e Content-Type: text/plain; charset=UTF-8 >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 >>> >>> >>> > > --f403045e9f50e28a9605480a7e5e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>Only the majorit= y needs to consent, though what is considered a majority varies depending o= n the context (95%, 75%, 51%). Nowhere does it say "everyone needs to = agree".

There's a pretty huge gap betwe= en 90% and nearly 100%. =C2=A090% excluding 10% only 7 times results in onl= y 48% of the original base.

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

Your definition of forward may be different than other users.

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

Yes, I chose Bitcoin because it relies on a strictly held consensus mecha= nism=C2=A0and not one that changes on the whims of the majority.=C2=A0 We h= ave tens of dozens of political currencies for that.

>When the 1MB cap was implemented it was stated specifically tha= t 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 didn't.=C2=A0 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.=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 sys= tem is voluntary, and you are free to leave at any time.
<= span style=3D"font-size:12.8px">
This seems to be venturing quite off topic, and perhaps would b= e better suited for the bitcoin-discuss list.

On Wed, Feb 8, 2017 at 1:56 PM, A= ndrew Johnson <andrew.johnson83@gmail.com> wrote:
If a small dissenti= ng minority can block all forward progress then bitcoin is no longer intere= sting.=C2=A0 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 o= f 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 resource= s) a few people(or make up a few online personas) to staunchly refuse to ac= cept anything at all and the entire system is stuck in 2013(when we first s= tarted widely discussing a blocksize increase seriously).

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

When th= e 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 hu= ge capacity.=C2=A0 Not sure where you got the idea that we all agreed to st= ay at 1MB forever, I certainly didn't.=C2=A0 It was never stated or imp= lied that we could change the coin cap later(please cite if I'm mistake= n).


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 will need to conse= nt.=C2=A0 The same rule applies to the cap, we all agreed to 21m, and if so= meone wants to change that, nearly everyone would need to agree.


On Feb 8, 2017 10:28 AM, "Andrew Johnson"= ; <andre= w.johnson83@gmail.com> wrote:
It i= s 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" <alp.bitcoin@gmail.com> wrote:
10% is not a tiny minorit= y.

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 netwo= rk 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.=C2=A0 That s= eems like a significant disenfranchisement and lack of consensus.

On Mon, Feb 6, 2017 at 2:25 PM, t. k= han via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
<= div>On Mon, Feb 6, 2017 at 2:53 PM, Luke Dashjr <luke@dashjr.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 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





--f403045e9f50e28a9605480a7e5e--