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 4CF64487 for ; Thu, 23 Jul 2015 23:57:09 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pd0-f169.google.com (mail-pd0-f169.google.com [209.85.192.169]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 289EC12E for ; Thu, 23 Jul 2015 23:57:08 +0000 (UTC) Received: by pdjr16 with SMTP id r16so3863842pdj.3 for ; Thu, 23 Jul 2015 16:57:07 -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=dFL/9ZahG9olvc3wr+uV01KJaoJVtCERo4UFePfHrDE=; b=Jr3M6mWoj4lfLWDjsVJIdu05h+mP1uQ0FdVIR5eo13V3U6npEivgZeM9F7a0sHdGYZ +8Zg4Hinj2Nky5c85IMuI6XO+M/h+0d2RO0Wzrecr3g9Fe62dVwqf4yS8LlQlZ5KtVzu T5xB/RnoGrGsWuM0DfDCxuviz3WeIhXQfMwvGqEy7CvSpvwwD827WHBIu2VTMuNCM1rM hK3Sdsb2EUJoRDGK70CM+0vEBligJQ86PLmOH+kAkmb6WV41YgR/ox2YTP5LfgkjRI2s +XLv9lbwSOWyiOVdovD0wPFA3eotqNTs1ZLvNJE7DGspudE2rBz0y8lwDxaiDiPQkXbg uJAQ== X-Received: by 10.70.128.34 with SMTP id nl2mr24370265pdb.43.1437695827735; Thu, 23 Jul 2015 16:57:07 -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 cl15sm10973792pdb.27.2015.07.23.16.57.04 (version=TLS1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 23 Jul 2015 16:57:05 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_1FA7162A-210C-4CD3-AEB5-8FCBDC37CAF8"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Eric Lombrozo In-Reply-To: Date: Thu, 23 Jul 2015 16:57:02 -0700 Message-Id: <42BF7FEB-320F-43BE-B3D9-1D76CB8B9975@gmail.com> References: <55B113AF.40500@thinlink.com> <6F436293-9E2B-461C-B105-FC4CF9EBFC69@gmail.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: Thu, 23 Jul 2015 23:57:09 -0000 --Apple-Mail=_1FA7162A-210C-4CD3-AEB5-8FCBDC37CAF8 Content-Type: multipart/alternative; boundary="Apple-Mail=_AA208FAB-16B2-4637-BB95-5C479EBDC609" --Apple-Mail=_AA208FAB-16B2-4637-BB95-5C479EBDC609 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > 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. 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=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=_AA208FAB-16B2-4637-BB95-5C479EBDC609 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
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=_AA208FAB-16B2-4637-BB95-5C479EBDC609-- --Apple-Mail=_1FA7162A-210C-4CD3-AEB5-8FCBDC37CAF8 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 iQIcBAEBCgAGBQJVsX9OAAoJEJNAI64YFENUtgwP/j+LngrVNyQs8E5yITf6YfBf qKjxtHQ1UOYnu2KCphZJdyRYag2dcR5ZHoWxkV9zHE9kAg9hsM5Yv1RpsuqzBCzP w39hI7+kKL3YInP8s0+mbnCCTMfus5TJ4n8sNdHNyVjb8w/fx0uIHTlQc2P1a3WP GQ4aueN+zipV06J94YMK2QAtl5sqKOktcJpW5N6iXdon85SnKQrI9SxVbcISzfO3 +riEyXxy8Tv5Cswo/xdLBgESj7sdfmjZ8TzvxkmGT/qIUqXUtnklK1FGXjp9PKl9 4eBD5heiqZ7T8lOrf+x4yK5c69cVaf1uEc2NGlrZp4ZdYSpT7KNM0sCQn++YisZO jlvlhXn+sHV+H6ZPwTONbHmj1YCZXiFHSe9ir/gG4+EfKs7nGrPZw9vAr/qkP9rN JkuCAOzLzwv6pf2ocamCY0iXI/4k6YpIfD2V2ewmRrRnPJ3zYPZQx9FhLXdfb0eZ dvtRPDFLgTnTn2p0XFei25nmCxOmwNvklK1c6xpmtZe0AkWhnXRyyFJ7mYO/Urpn s1Rm//H7+O1CE5BinVmDzd7xwLBsVil70S60sSRv624jnzCWuDhjxxfkMOO+TRH9 xJE75yILBl5NfO08+Geb15TQPqIpwJsNi9DKb2KBoXy8kbXy6F1G9JD8eFcvg0OR Yi9n/oqEFzAD/pMuE58a =xDib -----END PGP SIGNATURE----- --Apple-Mail=_1FA7162A-210C-4CD3-AEB5-8FCBDC37CAF8--