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 43E545AE for ; Wed, 22 Jul 2015 17:45:32 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 93089143 for ; Wed, 22 Jul 2015 17:45:31 +0000 (UTC) Received: by iehx8 with SMTP id x8so93226707ieh.3 for ; Wed, 22 Jul 2015 10:45:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CstGkpa0P5IpBs25RnFcnDRYD3Wsp9q93/aM6EnWdoQ=; b=eDkzlecgI0xf2peHcgg71SPHOdJeHO/Uab6cWHg195VxX3s3knJ9yMdSsji76+oZFN wHDCeyO/2o27ZfoLSkkhwXNZsDruOPbVoZdm9Whay6V50l8FJjJryTT4S6QVW+XfCS7K FbaC/bZuM9IjQ4Oi1AJ9Y8YSpwv6V7bW+WSCWtLYRgFXEP+sT47iTSOJXV/i5YEXCYYU jxuqG+0EJvhJn9ZsuvOmaBLPmlkJPnM/X6DqjLlQLvJ+eHFCTg2+N9nVdcwhR3c/Vjvq VNzz+h4YRwpU6Hxu+WSCYo8b49bNZ7b/r1V7GJz2u9njCtIzXh/vcn5uMRin1Y41Kt4s fNjQ== MIME-Version: 1.0 X-Received: by 10.50.3.6 with SMTP id 6mr34227211igy.28.1437586999381; Wed, 22 Jul 2015 10:43:19 -0700 (PDT) Received: by 10.79.38.79 with HTTP; Wed, 22 Jul 2015 10:43:19 -0700 (PDT) In-Reply-To: <20150721135846.GB13429@savin.petertodd.org> References: <55A9421B.6040605@jrn.me.uk> <55AC29DB.4060800@jrn.me.uk> <20150721130412.GA4551@savin.petertodd.org> <20150721135846.GB13429@savin.petertodd.org> Date: Wed, 22 Jul 2015 10:43:19 -0700 Message-ID: From: Jeff Garzik To: Peter Todd Content-Type: multipart/alternative; boundary=089e0122aa626ed54e051b7a4eb9 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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 17:45:32 -0000 --089e0122aa626ed54e051b7a4eb9 Content-Type: text/plain; charset=UTF-8 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. --089e0122aa626ed54e051b7a4eb9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jul 21, 2015 at 6:58 AM, Peter Todd via bitcoin-de= v <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&= #39;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 kno= ws
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.=C2=A0 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&qu= ot; as some has predicted.

Security, privacy and c= entralization are not going to disappear at 2MB.

F= urther, a limited step gains valuable field data for judging whether furthe= r 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 war= ranted, yet cannot reach consensus on a fancy, all-consuming solution be it= 20MB, flexcap, BIP 100, BIP 102, etc.

I am open t= o suggestions for improving BIP 102.=C2=A0 The goal is a minimum complexity= fallback that others have previously agreed was a useful kick-the-can comp= romise - a static 2MB cap.



--089e0122aa626ed54e051b7a4eb9--