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 B7EF449D for ; Wed, 22 Jul 2015 22:30:36 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail148110.authsmtp.com (outmail148110.authsmtp.com [62.13.148.110]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id E4C9BEA for ; Wed, 22 Jul 2015 22:30:35 +0000 (UTC) Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt16.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t6MMUWdX062696; Wed, 22 Jul 2015 23:30:32 +0100 (BST) Received: from [25.157.251.156] ([24.114.64.222]) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t6MMUSmM005580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Jul 2015 23:30:29 +0100 (BST) In-Reply-To: References: <55A9421B.6040605@jrn.me.uk> <55AC29DB.4060800@jrn.me.uk> <20150721130412.GA4551@savin.petertodd.org> <20150721135846.GB13429@savin.petertodd.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Peter Todd Date: Wed, 22 Jul 2015 22:30:25 +0000 To: Jeff Garzik Message-ID: X-Server-Quench: 4284a6a2-30c1-11e5-b397-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdAAUEkAYAgsB AmMbWVdeU117WmM7 aQ5PbARZfExKQQdo UldNRFdNFUssB2F8 Y31DLxlycgBOeDBx YUFiVj5fXkx+JEAs QFNXFT4HeGZhPWUC AkNRcB5UcAFPdx8U a1UrBXRDAzANdhEy HhM4ODE3eDlSNhEd aCA1ZQtKGw5OVj09 TBNKATUiVUYMQW0/ KAMgYkIcEQ4LNUw+ eUcmEQg9GXc8 X-Authentic-SMTP: 61633532353630.1023:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 24.114.64.222/465 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 22:30:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Sorry, but I think you need to re-read my first message. What you've written below has nothing to do with what I actually said re: how you're BIP102 and associated pull-req doesn't measure miner consensus. On 22 July 2015 13:43:19 GMT-04:00, Jeff Garzik wrote: >On Tue, Jul 21, 2015 at 6:58 AM, Peter Todd via bitcoin-dev < >bitcoin-dev@lists.linuxfoundation.org> wrote: > >> I don't agree with you at all. >> >> This is a case where if Jeff doesn't understand that issue, he's >> proposing changes that he's not competent enough to understand, and >it'd >> save us a lot of review effort if he left that discussion. Equally, >Jeff >> is in a position in the dev community where he should be that >competent; >> if he actually isn't it does a lot of good for the broader community >to >> change that opinion. >> >> I personally *don't* think he's doing that, rather I believe he knows >> full well it's a bad patch and is proposing it because he wants to >push >> discussion towards a solution. Often trolling the a audience with bad >> patches is an effective way to motivate people to respond by writing >> better ones; Jeff has told me he often does exactly that. >> >> >mmmm kay. Let's try to keep it technical, please. > >2MB is a limit that has been discussed as a viable next-step, meeting >with >the most consensus. > >2MB gets beyond the 1MB hard fork issue, while still remaining within a >safety cap that should ensure the system does not go "off the rails" as >some has predicted. > >Security, privacy and centralization are not going to disappear at 2MB. > >Further, a limited step gains valuable field data for judging whether >further steps are warranted - thus informing the "better block size >solution" development process. > >Finally, as stated in the initial PR, it is intended as a viable >fallback >should we reach a point of criticality where the user community feels a >block size increase is warranted, yet cannot reach consensus on a >fancy, >all-consuming solution be it 20MB, flexcap, BIP 100, BIP 102, etc. > >I am open to suggestions for improving BIP 102. The goal is a minimum >complexity fallback that others have previously agreed was a useful >kick-the-can compromise - a static 2MB cap. -----BEGIN PGP SIGNATURE----- iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVsBl2 AAoJEMCF8hzn9Lnc47AIAICM9pA+Jc6rkJ14U0vYqzhwTHmxuaNTXodmI1z88OKM zCCJQHNw/Xhy339/ZGFeUuVS/Csw275dtzZutLoZamnGnQLh9LllxYFzN8eGJkCL Ecfo0JcyhduwUihgDfzgE++z5/Q0z5sIo+pZBNipqXW1+N0P/GAvYlHqeb9r0uXG ccJghZUTwqzm6aySfvXVveTmp0AtjVko1jP1sTxF2pI/RIqBdMY4wEsZvmEhX7Tk g2iRiPWiEIYR1qETm6e5aQ/tj8W73932s15ozIM35nD5QId5qotQHTVttLAruQvl 2Z35F79TIYDvYtnnRNWIsOyiwreH/y5c0kSUIgrjASA= =+jTv -----END PGP SIGNATURE-----