From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z5hpR-0003T4-74 for bitcoin-development@lists.sourceforge.net; Thu, 18 Jun 2015 21:58:33 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of bitpay.com designates 209.85.218.42 as permitted sender) client-ip=209.85.218.42; envelope-from=jgarzik@bitpay.com; helo=mail-oi0-f42.google.com; Received: from mail-oi0-f42.google.com ([209.85.218.42]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Z5hpQ-0003W7-CT for bitcoin-development@lists.sourceforge.net; Thu, 18 Jun 2015 21:58:33 +0000 Received: by oigb199 with SMTP id b199so25981768oig.3 for ; Thu, 18 Jun 2015 14:58:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=iJM9WuEplm/AQHKFuEkXWwy4h6kDYubqABrcHusK4s0=; b=P0A5IR87jt48vO3KieKwLi1Ex59WZ5D2JIvYRPgLgP31cSTdphy5dDtLR5/WEY+XXS fPJMGA4KBJIOJzSnwWrc6su3DNV3DrwexCxui5+65aIixypzs6d5TcxmapgJH+4EKRgo /gp+QkCITQEQtvnxnFgZMGuyfhROq++TVCk6176ke5+4BLitTYLz8+oxBGqwLt8kfwsI UfJ5WSFGHhnNeiZvRnWbY0SOJLg7SKlhZVTg6r2DlKb4bCDLfDt0m7IXYD1uSUUO4zcQ GYMDDZcWwkWpQHSf3lBYjft5NV3qLNis59h8ABXESla87SRZgIYgAVPqY+YOLC1YWawO o/nQ== X-Gm-Message-State: ALoCoQnXRcw1qFH363QrvER6MLwxxg8ujQNogq7o+m/7kkAUsDAUWukv0Ww9rVTJ1FY3vGIPkuv1 X-Received: by 10.182.86.9 with SMTP id l9mr10851150obz.61.1434664706941; Thu, 18 Jun 2015 14:58:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.108.149 with HTTP; Thu, 18 Jun 2015 14:58:06 -0700 (PDT) In-Reply-To: References: <55828737.6000007@riseup.net> <55831CAB.2080303@jrn.me.uk> <1867667.WXWC1C9quc@crushinator> From: Jeff Garzik Date: Thu, 18 Jun 2015 14:58:06 -0700 Message-ID: To: Mark Friedenbach Content-Type: multipart/alternative; boundary=089e014954c83ace7a0518d1e821 X-Spam-Score: -0.2 (/) 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 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.4 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1Z5hpQ-0003W7-CT Cc: Bitcoin Development , Gavin Andresen Subject: Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers 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: Thu, 18 Jun 2015 21:58:33 -0000 --089e014954c83ace7a0518d1e821 Content-Type: text/plain; charset=UTF-8 Is that a forward-looking position? It does not seem so. The whole point is getting out in front of the need, to prevent significant negative impact to users when blocks are consistently full. To do that, you need to (a) plan forward, in order to (b) set a hard fork date in the future. "We don't see a need today" is therefore useless, because when you do reach X day when need is apparent, the best solution then becomes an immediate fork for which the network and markets are not prepared. Failing to resolve the block size issue soon will simply result in most businesses assuming relevant Bitcoin Core standards process is failing, and proceed with the Bitcoin-XT fork. As I've said on IRC, the "do nothing, for now" position is untenable. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ --089e014954c83ace7a0518d1e821 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Is that a forward-looking position?=C2=A0 It does not seem= so.

The whole point is getting out in front of the need= , to prevent significant negative impact to users when blocks are consisten= tly full.

To do that, you need to (a) plan forward= , in order to (b) set a hard fork date in the future.

<= div>"We don't see a need today" is therefore useless, because= when you do reach X day when need is apparent, the best solution then beco= mes an immediate fork for which the network and markets are not prepared.

Failing to resolve the block size issue soon will s= imply result in most businesses assuming relevant Bitcoin Core standards pr= ocess is failing, and proceed with the Bitcoin-XT fork.

As I've said on IRC, the "do nothing, for now" position= is untenable.

--
Jeff Garzik
Bitcoin core developer and open sou= rce evangelist
BitPay, Inc. =C2=A0 =C2=A0 =C2=A0https://bitpay.com/
--089e014954c83ace7a0518d1e821--