From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YyKqP-0007er-0l for bitcoin-development@lists.sourceforge.net; Fri, 29 May 2015 14:01:05 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of national.shitposting.agency designates 75.102.27.230 as permitted sender) client-ip=75.102.27.230; envelope-from=insecurity@national.shitposting.agency; helo=mail.cock.li; Received: from cock.li ([75.102.27.230] helo=mail.cock.li) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1YyKqN-0001H2-5O for bitcoin-development@lists.sourceforge.net; Fri, 29 May 2015 14:01:05 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 29 May 2015 14:00:54 +0000 From: insecurity@national.shitposting.agency To: Gavin Andresen In-Reply-To: References: <16096345.A1MpJQQkRW@crushinator> Message-ID: X-Sender: insecurity@national.shitposting.agency User-Agent: Roundcube Webmail/0.9.5 X-Spam-Score: -1.5 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1YyKqN-0001H2-5O Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB step function X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 14:01:05 -0000 Are you really that pig headed that you are going to try and blow up the entire system just to get your way? A bunch of ignorant redditors do not make consensus, mercifully. On 2015-05-29 12:39, Gavin Andresen wrote: > What do other people think? > > If we can't come to an agreement soon, then I'll ask for help > reviewing/submitting patches to Mike's Bitcoin-Xt project that > implement a big increase now that grows over time so we may never have > to go through all this rancor and debate again. > > I'll then ask for help lobbying the merchant services and exchanges > and hosted wallet companies and other bitcoind-using-infrastructure > companies (and anybody who agrees with me that we need bigger blocks > sooner rather than later) to run Bitcoin-Xt instead of Bitcoin Core, > and state that they are running it. We'll be able to see uptake on the > network by monitoring client versions. > > Perhaps by the time that happens there will be consensus bigger blocks > are needed sooner rather than later; if so, great! The early > deployment will just serve as early testing, and all of the software > already deployed will ready for bigger blocks. > > But if there is still no consensus among developers but the "bigger > blocks now" movement is successful, I'll ask for help getting big > miners to do the same, and use the soft-fork block version voting > mechanism to (hopefully) get a majority and then a super-majority > willing to produce bigger blocks. The purpose of that process is to > prove to any doubters that they'd better start supporting bigger > blocks or they'll be left behind, and to give them a chance to upgrade > before that happens. > > Because if we can't come to consensus here, the ultimate authority for > determining consensus is what code the majority of merchants and > exchanges and miners are running. > > -- > > -- > Gavin Andresen > > ------------------------------------------------------------------------------ > > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development