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-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YqNqQ-0001BO-FC for bitcoin-development@lists.sourceforge.net; Thu, 07 May 2015 15:36:14 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of bitpay.com designates 209.85.218.43 as permitted sender) client-ip=209.85.218.43; envelope-from=jgarzik@bitpay.com; helo=mail-oi0-f43.google.com; Received: from mail-oi0-f43.google.com ([209.85.218.43]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YqNqP-0005gz-Ea for bitcoin-development@lists.sourceforge.net; Thu, 07 May 2015 15:36:14 +0000 Received: by oift201 with SMTP id t201so36473461oif.3 for ; Thu, 07 May 2015 08:36:08 -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=+1fMBIftiAUcmYcCObONDFim4ygeyEWQucSOf20b0BI=; b=bx2iWuhRNq2EfCqboEO2koXpsbCHbbMUJJDc60PdkstdgyAeqJyy6n38wVWLdA3sYl 82SgR3nVydcDgXsFFm/caegStCEiV+aNiwyVN/xQEsd6nHtQ4UO8cUymKZjIvBGSB3sJ EKYeu0nxYUr2aeVDJbZcdSseGMzYqCzEgsgEvc89VN6DSHICY4QrSjJ9OeH2JNwnCDdK 4Y5RAzkLRx+AlUg1lLW1FnH34zplgiE3yRSdapgkpo3CjQhL1Gex2oberrjNYF2HYgTU 4tqavGjtmNj1Mj9jLsNzFUhDthod5494svIcBRWSpKFEUoenEh5yLtHqaoSvw2xGkGDY NoxQ== X-Gm-Message-State: ALoCoQnI/Z2ZZ31wvbcx1Kkl/ioqffDqcUnHgWI7ygVPvvs8llZeiQjH6EjirIZcR7KVKy/lLa5j X-Received: by 10.60.176.33 with SMTP id cf1mr2103041oec.24.1431012968038; Thu, 07 May 2015 08:36:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.108.149 with HTTP; Thu, 7 May 2015 08:35:47 -0700 (PDT) In-Reply-To: References: <554A91BE.6060105@bluematt.me> From: Jeff Garzik Date: Thu, 7 May 2015 11:35:47 -0400 Message-ID: To: Mike Hearn Content-Type: multipart/alternative; boundary=089e01176281a11a6d05157fabf6 X-Spam-Score: -0.6 (/) 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 X-Headers-End: 1YqNqP-0005gz-Ea Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Block Size Increase 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, 07 May 2015 15:36:14 -0000 --089e01176281a11a6d05157fabf6 Content-Type: text/plain; charset=UTF-8 Yes - but you must recognize that is precisely 50% of the picture. Others have made different assumptions - taking the [1MB-constrained] market *as it exists today*, rather than in some projected future. Raising the block size limit then becomes a *human decision* to favor some users over others, a *human decision* to prevent an active and competitive free fee market developing at 1MB, a *human decision* to keep transaction fees low to incentivize bitcoin adoption, a *human decision* to value adoption over decentralization. These statements are not value judgements - not saying you are wrong - these are observations of some rather huge, relevant blind spots in this debate. On Thu, May 7, 2015 at 11:29 AM, Mike Hearn wrote: > It is a trivial *code* change. It is not a trivial change to the >> economics of a $3.2B system. >> > > Hmm - again I'd argue the opposite. > > Up until now Bitcoin has been unconstrained by the hard block size limit. > > If we raise it, Bitcoin will continue to be unconstrained by it. That's > the default "continue as we are" position. > > If it's not raised, then ....... well, then we're in new territory > entirely. Businesses built on the assumption that Bitcoin could become > popular will suddenly have their basic assumptions invalidated. Users will > leave. The technical code change would be zero, but the economic change > would be significant. > -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ --089e01176281a11a6d05157fabf6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes - but you must recognize that is precis= ely 50% of the picture.

Others have made different assumptions= - taking the [1MB-constrained] market as it exists today, rather th= an in some projected future.

Raising the block size limit then= becomes a human decision to favor some users over others, a huma= n decision to prevent an active and competitive free fee market develop= ing at 1MB, a human decision to keep transaction fees low to incenti= vize bitcoin adoption, a human decision to value adoption over decen= tralization.

These statements are not value judgements - not s= aying you are wrong - these are observations of some rather huge, relevant = blind spots in this debate.




=

On Thu, May 7, 20= 15 at 11:29 AM, Mike Hearn <mike@plan99.net> wrote:
It is = a trivial code change.=C2=A0 It is not a trivial change to the econo= mics of a $3.2B system.

=
Hmm - again I'd argue the opposite.

Up until now Bitcoin has been unconstrained by the hard block size limit.=

If we raise it, Bitcoin will continue to be uncon= strained by it. That's the default "continue as we are" posit= ion.

If it's not raised, then ....... well, th= en we're in new territory entirely. Businesses built on the assumption = that Bitcoin could become popular will suddenly have their basic assumption= s invalidated. Users will leave. The technical code change would be zero, b= ut the economic change would be significant.



--
Jeff Garzik
Bitcoin core developer and open source evangelistBitPay, Inc. =C2=A0 =C2=A0 =C2=A0https://bitpay.com/
--089e01176281a11a6d05157fabf6--