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 EDFAB5AC for ; Fri, 10 Feb 2017 04:10:20 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outgoing.millersville.edu (outgoing.millersville.edu [166.66.86.75]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 2E19618D for ; Fri, 10 Feb 2017 04:10:20 +0000 (UTC) X-ASG-Debug-ID: 1486699816-0793ff17841437b0001-D3WCip Received: from HUBCAS2.muad.local (hubcas2.muad.local [166.66.87.94]) by outgoing.millersville.edu with ESMTP id UNq5LoKmNh0p0tCH for ; Thu, 09 Feb 2017 23:10:16 -0500 (EST) X-Barracuda-Envelope-From: rjmarti2@millersville.edu X-Barracuda-Effective-Source-IP: hubcas2.muad.local[166.66.87.94] X-Barracuda-Apparent-Source-IP: 166.66.87.94 Received: from STUDMAIL1.muad.local ([2002:a642:56b8::a642:56b8]) by HUBCAS2.muad.local ([2002:a642:575e::a642:575e]) with mapi id 14.03.0301.000; Thu, 9 Feb 2017 23:10:16 -0500 From: Ryan J Martin To: "bitcoin-dev@lists.linuxfoundation.org" Thread-Topic: [bitcoin-dev] A Modified Version of Luke-jr's Block Size BIP X-ASG-Orig-Subj: Re: [bitcoin-dev] A Modified Version of Luke-jr's Block Size BIP Thread-Index: AQHSg0wDvjWBZfRzqECU1DRpu5FnAg== Date: Fri, 10 Feb 2017 04:10:15 +0000 Message-ID: <127281C1AA02374F8AAD9EE04FAE878A02154E80BD@STUDMail1.muad.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [71.207.55.31] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: hubcas2.muad.local[166.66.87.94] X-Barracuda-Start-Time: 1486699816 X-Barracuda-URL: https://166.66.86.75:443/cgi-mod/mark.cgi X-Barracuda-Scan-Msg-Size: 4677 X-Virus-Scanned: by bsmtpd at millersville.edu X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=4.5 KILL_LEVEL=1000.0 tests=MAILTO_TO_SPAM_ADDR X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.36427 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 MAILTO_TO_SPAM_ADDR Includes a link to a likely spammer email X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_NONE, RP_MATCHES_RCVD 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: Fri, 10 Feb 2017 10:23:41 +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 04:10:21 -0000 "10% say literally never. That seems like a significant disenfranchisement= =0A= and lack of consensus."=0A= =0A= Certainly the poll results should be taken with a grain of salt and not a d= efinitive answer or measure . =0A= However if we agree the poll has some worth (or even if not, then lets use = it as hyptothetical): If we split it into two groups: those okay with a har= dfork at some point > now, and those never okay with hardfork, that means t= here is 90% that agree a hardfork is acceptable in the future. That said, w= hat threshold defines consensus then? 98%? 100%? =0A= =0A= Personally I think pursuing paths that maximize net social benefit in terms= of cost surplus/burden is the best way to go since consensus is such an im= possible to define, variable, case-by-case thing that doesn't always lead t= o the best choice.=0A= =0A= -Ryan J. MArtin=0A= =0A= =0A= ________________________________________=0A= From: bitcoin-dev-bounces@lists.linuxfoundation.org [bitcoin-dev-bounces@li= sts.linuxfoundation.org] on behalf of bitcoin-dev-request@lists.linuxfounda= tion.org [bitcoin-dev-request@lists.linuxfoundation.org]=0A= Sent: Thursday, February 09, 2017 7:00 AM=0A= To: bitcoin-dev@lists.linuxfoundation.org=0A= Subject: bitcoin-dev Digest, Vol 21, Issue 10=0A= =0A= Send bitcoin-dev mailing list submissions to=0A= bitcoin-dev@lists.linuxfoundation.org=0A= =0A= To subscribe or unsubscribe via the World Wide Web, visit=0A= https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev=0A= or, via email, send a message with subject or body 'help' to=0A= bitcoin-dev-request@lists.linuxfoundation.org=0A= =0A= You can reach the person managing the list at=0A= bitcoin-dev-owner@lists.linuxfoundation.org=0A= =0A= When replying, please edit your Subject line so it is more specific=0A= than "Re: Contents of bitcoin-dev digest..."=0A= =0A= =0A= Today's Topics:=0A= =0A= 1. Re: A Modified Version of Luke-jr's Block Size BIP (alp alp)=0A= =0A= =0A= ----------------------------------------------------------------------=0A= =0A= Message: 1=0A= Date: Wed, 8 Feb 2017 08:44:52 -0600=0A= From: alp alp =0A= To: "t. khan" , Bitcoin Protocol Discussion=0A= =0A= Subject: Re: [bitcoin-dev] A Modified Version of Luke-jr's Block Size=0A= BIP=0A= Message-ID:=0A= =0A= Content-Type: text/plain; charset=3D"utf-8"=0A= =0A= 10% say literally never. That seems like a significant disenfranchisement= =0A= and lack of consensus.=0A= =0A= On Mon, Feb 6, 2017 at 2:25 PM, t. khan via bitcoin-dev <=0A= bitcoin-dev@lists.linuxfoundation.org> wrote:=0A= =0A= > On Mon, Feb 6, 2017 at 2:53 PM, Luke Dashjr wrote:=0A= >=0A= >> On Monday, February 06, 2017 6:19:43 PM you wrote:=0A= >> > >My BIP draft didn't make progress because the community opposes any= =0A= >> block=0A= >> > >size increase hardfork ever.=0A= >> >=0A= >> > Luke, how do you know the community opposes that? Specifically, how di= d=0A= >> you=0A= >> > come to this conclusion?=0A= >>=0A= >> http://www.strawpoll.me/12228388/r=0A= >=0A= >=0A= > That poll shows 63% of votes want a larger than 1 MB block by this summer= .=0A= > How do you go from that to "the community opposes any block increase ever= "?=0A= > It shows the exact opposite of that.=0A= >=0A= >=0A= >> > >Your version doesn't address the current block size=0A= >> > >issues (ie, the blocks being too large).=0A= >> >=0A= >> > Why do you think blocks are "too large"? Please cite some evidence. I'= ve=0A= >> > asked this before and you ignored it, but an answer would be helpful t= o=0A= >> the=0A= >> > discussion.=0A= >>=0A= >> Full node count is far below the safe minimum of 85% of economic activit= y.=0A= >>=0A= >=0A= > Is this causing a problem now? If so, what?=0A= >=0A= >=0A= >> Typically reasons given for people not using full nodes themselves come= =0A= >> down=0A= >> to the high resource requirements caused by the block size.=0A= >=0A= >=0A= > The reason people stop running nodes is because there's no incentive to= =0A= > counteract the resource costs. Attempting to solve this by making blocks= =0A= > *smaller* is like curing a disease by killing the patient. (Incentivizing= =0A= > full node operation would fix that problem.)=0A= >=0A= > - t.k.=0A= >=0A= >=0A= > _______________________________________________=0A= > bitcoin-dev mailing list=0A= > bitcoin-dev@lists.linuxfoundation.org=0A= > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev=0A= >=0A= >=0A= -------------- next part --------------=0A= An HTML attachment was scrubbed...=0A= URL: =0A= =0A= ------------------------------=0A= =0A= _______________________________________________=0A= bitcoin-dev mailing list=0A= bitcoin-dev@lists.linuxfoundation.org=0A= https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev=0A= =0A= =0A= End of bitcoin-dev Digest, Vol 21, Issue 10=0A= *******************************************=0A=