Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id BE5C3499 for ; Fri, 24 Jul 2015 00:04:13 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0F1B8137 for ; Fri, 24 Jul 2015 00:04:13 +0000 (UTC) Received: by pabkd10 with SMTP id kd10so4110205pab.2 for ; Thu, 23 Jul 2015 17:04:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=xbtx+oki8z8jfWKe/kHCEkT0JsvVwU20906FS606YRw=; b=bp7X8ZTX12bhyzemrECy+X9IYdY8ZmBh+xkTElNzQNwQPFxZg2VpBFc84nA0aRT3rU Q7Z3wyggYs5IXPo20wk+ZtzBuyIvzrOg8EhMBOKBpDL3eRH+EPThigDqDZkd5dJvYoMd t9o6qChPdFt/Sk201jh4hQ65hwvjCzBcgiMHNHij5n/pBOdPnJOcySb/McERW4EzoGO5 sINiwNM1WaYb++5QAsn3DQ3Jqjcvj15+2GUsccsVxCQ7wzaKZ6guCBUYH5Zgvxm8au3W iKOqgObaj3rzWc6oKgHV3jln4/qgwrLmWt9YOo1xXW5worlJdKQkBlbjJraK7Eu5nwmA CWTQ== X-Received: by 10.70.94.42 with SMTP id cz10mr24271961pdb.92.1437696252638; Thu, 23 Jul 2015 17:04:12 -0700 (PDT) Received: from [192.168.1.107] (cpe-76-167-237-202.san.res.rr.com. [76.167.237.202]) by smtp.gmail.com with ESMTPSA id v9sm10940145pdr.96.2015.07.23.17.04.09 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 23 Jul 2015 17:04:10 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_36BD3FB1-1EAD-4696-A031-B37DAD5E2CA4"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Eric Lombrozo In-Reply-To: <42BF7FEB-320F-43BE-B3D9-1D76CB8B9975@gmail.com> Date: Thu, 23 Jul 2015 17:04:07 -0700 Message-Id: References: <55B113AF.40500@thinlink.com> <6F436293-9E2B-461C-B105-FC4CF9EBFC69@gmail.com> <42BF7FEB-320F-43BE-B3D9-1D76CB8B9975@gmai l.com> To: Benedict Chan X-Mailer: Apple Mail (2.2098) 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] Bitcoin Core and hard forks 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: Fri, 24 Jul 2015 00:04:13 -0000 --Apple-Mail=_36BD3FB1-1EAD-4696-A031-B37DAD5E2CA4 Content-Type: multipart/alternative; boundary="Apple-Mail=_61ABB561-AD10-4503-B84E-9281227F90AF" --Apple-Mail=_61ABB561-AD10-4503-B84E-9281227F90AF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I should also add that I think those who claim that fee pressure will = scare away users and break the industry are *seriously* underestimating = human ingenuity in the face of a challenge. We can do this - we can = overcome this obstacle=E2=80=A6we can find good solutions to a fee = market. Unless someone can come up with another way to pay for the = operation of the network, we NEED to do this. What makes anyone think it = will be easier to do later rather than now? The longer we wait, the = lower block rewards get, the larger the deployed infrastructure, the = larger our userbase, the HARDER it will be to solve it. We should solve = it now - we will be much better off for it=E2=80=A6and so will our = users. > On Jul 23, 2015, at 4:57 PM, Eric Lombrozo = wrote: >=20 >=20 >> On Jul 23, 2015, at 4:42 PM, Benedict Chan > wrote: >>=20 >> Scaling the network will come in the form of a combination of many >> optimizations. Just because we do not know for sure how to eventually >> serve 7 billion people does not mean we should make decisions on >> global validation that impact our ability to serve the current set of >> users. >=20 > Agreed. But I believe the economic and security arguments I gave = regarding fees and incentives still hold and are largely separate from = the scalability issue. Please correct me if I overlooked something. >=20 >=20 >> Also, blocking a change because it's "more important to address = issues >> such as..." other improvements will further slow down the discussion. >> I believe an increase will not prevent the development of other >> improvements that we need - in contrast, the sooner we can get over >> the limit (which, as you agree, needs to be changed at some point), >> the sooner we can get back to work. >=20 > An increase in block size at this time will exacerbate security = concerns around nodes relying on other nodes to validate (particularly = miners and wallets). It=E2=80=99s not really a matter of having limited = developer resources that need to be budgeted, as you seem to suggest. >=20 > Regarding developments on properly handling fees, there must exist the = economic need for it before there=E2=80=99s an earnest effort to solve = it. Increasing the block size right now will, in all likelihood, delay = this effort. I=E2=80=99d much prefer to first let the fee market evolve = because it=E2=80=99s a crucial component to the protocol=E2=80=99s = design and its security model=E2=80=A6and so we can get a better sense = for fee economics. Then we might be able to figure out better approaches = to block size changes in the future that makes sense = economically=E2=80=A6perhaps with mechanisms that can dynamically adjust = it to reflect resource availability and network load. --Apple-Mail=_61ABB561-AD10-4503-B84E-9281227F90AF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I should also add that I think those who claim that fee = pressure will scare away users and break the industry are *seriously* = underestimating human ingenuity in the face of a challenge. We can do = this - we can overcome this obstacle=E2=80=A6we can find good solutions = to a fee market. Unless someone can come up with another way to pay for = the operation of the network, we NEED to do this. What makes anyone = think it will be easier to do later rather than now? The longer we wait, = the lower block rewards get, the larger the deployed infrastructure, the = larger our userbase, the HARDER it will be to solve it. We should solve = it now - we will be much better off for it=E2=80=A6and so will our = users.


On = Jul 23, 2015, at 4:57 PM, Eric Lombrozo <elombrozo@gmail.com>= wrote:


On Jul 23, 2015, at 4:42 PM, Benedict Chan <bencxr@fragnetics.com> wrote:

Scaling the network will come in the form of a = combination of many
optimizations. Just = because we do not know for sure how to eventually
serve 7 billion people does not mean we should = make decisions on
global validation that = impact our ability to serve the current set of
users.

Agreed. But I believe the economic and = security arguments I gave regarding fees and incentives still hold and = are largely separate from the scalability issue. Please correct me if I = overlooked something.


Also, blocking a change = because it's "more important to address issues
such as..." other improvements will further slow = down the discussion.
I believe an increase will = not prevent the development of other
improvements that we need - in contrast, the = sooner we can get over
the limit (which, as you = agree, needs to be changed at some point),
the sooner we can get back to work.

An = increase in block size at this time will exacerbate security concerns = around nodes relying on other nodes to validate (particularly miners and = wallets). It=E2=80=99s not really a matter of having limited developer = resources that need to be budgeted, as you seem to suggest.

Regarding developments = on properly handling fees, there must exist the economic need for it = before there=E2=80=99s an earnest effort to solve it. Increasing the = block size right now will, in all likelihood, delay this effort. I=E2=80=99= d much prefer to first let the fee market evolve because it=E2=80=99s a = crucial component to the protocol=E2=80=99s design and its security = model=E2=80=A6and so we can get a better sense for fee economics. Then = we might be able to figure out better approaches to block size changes = in the future that makes sense economically=E2=80=A6perhaps with = mechanisms that can dynamically adjust it to reflect resource = availability and network load.

= --Apple-Mail=_61ABB561-AD10-4503-B84E-9281227F90AF-- --Apple-Mail=_36BD3FB1-1EAD-4696-A031-B37DAD5E2CA4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVsYD3AAoJEJNAI64YFENUEdcP/iX5WaIqAP2H1gPdkFGaG/re A4wxC4GPuS5/549C77yU0GC1DkYQW/bThG5NsGMt3nOTXimlEoaoIveehd0nCz3H YlaivLsJtv04UR+u1ymChn5kWdkxyuAgXAcYNDL08Tu+JByYU/VB5AYmfxPePZdN NRnAUPdN22BOy5yIZ6OK7XYiBZFnETSmHJQnFS9IUHytXHj/mANyAKwkE1O/QUbK hN6WNWm1vMITd+RZMHdFmmnx+XOvwALP9zh0I/bm8DzcTqHPdsxzexTf73Sr8IZO XVvL76j0lsSfyziGgIzKKD6lj2sDfTkus0OY7DkZ80oiJAyDSCg+GhILK37gpy0v joUl3C3vkDGsqSQvrODZ+MZ9yDYjvIa3RIKPu6EJ4nWMIDHl6bMnSyCHt6Lk1Y4L vljUPbVFvCywwkReEXwuz+9p4cOZSqJwAfvqigygwkyT5PR3g54qrHtXld4i9C+M TSzmnL5NZhwvV8kqBwh1Z8q5EVR6/Q3l52P4kKwtmy4JGOlDc4Bbn4Gg8AuhSph3 fTxWOpDgHWKWJndqIa7DX+AumuV5ICNLYtDHNsKyoRyC8jfdEjG2WqfZmjkMxqk5 v8dk0c5pCcrr7S1LEDp/KeyHgSFTHoUrkklLW6zonM/yxCoxbY+TURhjMNvUv51y Yt0Oio26WiZOpQId6umB =QQnZ -----END PGP SIGNATURE----- --Apple-Mail=_36BD3FB1-1EAD-4696-A031-B37DAD5E2CA4--