Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 39100323 for ; Sat, 27 Jun 2015 02:18:25 +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 9F5BBE3 for ; Sat, 27 Jun 2015 02:18:24 +0000 (UTC) Received: by padev16 with SMTP id ev16so76975236pad.0 for ; Fri, 26 Jun 2015 19:18:24 -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=hkyfIjnRMxcBriVuN9R6GNdM3efbRa3KJ+pyORFLKfQ=; b=vEIV6lDkiPYAwnlk22tz0FXlMQpXn3klNgPbc7kmFfyXWPj7/GF0GmlwGKuoGg4QAz zYNugba8PWy9126GiC+PSiphYgiIEAMcKD99/TbdDzVWnYHixGbmj92DovxhJ+PjrEGG 7iVrbKG7mou/8KAvxFX8L46vFLgFjAM8l9YTfEIeGnSAW6QQ88Ph4snMYgzekEW5Ivaz CGqTeZItVfxfDxoL4TfmvIwEQFt9itQN+n5mVqAZSLW1R1QQzpiCOy/+NJbBk5TaeNqo oCp3mmPFQe2WV+a/YGJkGWciEKVyKOeJZpDd0kOPFBjeESjmHsVtdqRHm/esMyG7GIV8 BIbw== X-Received: by 10.70.138.8 with SMTP id qm8mr8973525pdb.96.1435371504368; Fri, 26 Jun 2015 19:18:24 -0700 (PDT) Received: from [192.168.1.102] (cpe-76-167-237-202.san.res.rr.com. [76.167.237.202]) by mx.google.com with ESMTPSA id qs8sm34631373pbc.38.2015.06.26.19.18.22 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 26 Jun 2015 19:18:23 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_353D3AD3-5AC9-48E7-8B36-9E33D23E79B8"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Eric Lombrozo In-Reply-To: <558DB997.4030209@phauna.org> Date: Fri, 26 Jun 2015 19:18:20 -0700 Message-Id: <2107342B-1D9E-4575-B7E4-3B69D51B1A17@gmail.com> References: <558DB997.4030209@phauna.org> To: Owen Gunden 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, MIME_QP_LONG_LINE, 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] The need for larger blocks 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: Sat, 27 Jun 2015 02:18:25 -0000 --Apple-Mail=_353D3AD3-5AC9-48E7-8B36-9E33D23E79B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99ve been pondering this whole scale issue considerably=E2=80=A6an= d am left with the conclusion that blockchains are ultimately dispute = resolution mechanisms. The vast majority of crypto negotiation will be = taking place at levels lesser than global consensus in the future - = global consensus is just far too expensive to require for every single = cappuccino. There really is little need to take most cases = globally=E2=80=A6unless the participants disagree. I=E2=80=99ve = commented in other places that blockchains are essentially a =E2=80=9Cfix=E2= =80=9D to the prisoner=E2=80=99s dilemma - they make cooperation the = equilibrium strategy. Regardless of whatever linear factor we scale the blockchain by, it is = simple math to see that any exponential growth (even if for a short = time) in usage will overwhelm the current network. If we ever intend to = take bitcoin mainstream, we will most likely experience at least a short = time of exponential growth=E2=80=A6at least until we either reach an = inherent limitation or until we saturate. As Pieter said earlier, FAPP = right now the demand for payments might as well be infinite. We=E2=80=99re= nowhere near the ability to service it all. The block size issue is really a usability issue at this point. There = are two fundamental things we need to solve: 1) There=E2=80=99s no model for how we=E2=80=99ll introduce a fee = market, even though the design of Bitcoin fundamentally depends on fees = for its survival (at least in the current form of the design.) 2) There=E2=80=99s no mechanism for how to perform fee bidding and = estimation. Most wallets simply have no way to do this without serious = usability problems. If we=E2=80=99re going to talk about block fees, let=E2=80=99s keep it = in the context of these relevant issues and not confound it with the = scalability issue=E2=80=A6these are two very different issues. - Eric Lombrozo > On Jun 26, 2015, at 1:44 PM, Owen Gunden wrote: >=20 > On 06/26/2015 02:23 PM, Jeff Garzik wrote: >> Failure to plan now for a hard fork increase 6(?) months in the = future >> produces that lumpy, unpredictable market behavior. >>=20 >> The market has baked in the years-long behavior of low fees. =46rom = the >> market PoV, inaction does lead to precisely that, a sudden change = over >> the span of a few months. >=20 > Which market participants are you referring to? >=20 > I entered the bitcoin market with open eyes, aware that it faces hard = scalability challenges by design. I was also aware that because of these = challenges, eventually transaction fees would have to rise. >=20 > Nevertheless, I made the decision to invest because of the utility I = gain from the anti-censorship, privacy, control, store of value, and = security aspects of bitcoin -- many of which stem from decentralization, = which others have demonstrated to be linked to the block size. >=20 > On the other hand, there are undoubtedly other market participants who = heard hype about "zero fee transactions to anywhere in the world", = believed it would scale, and made (mal)investments as a result. >=20 > As for how many market participants of each flavor, and how deep their = respective pockets, who knows? My experience in markets has lead me to = realize that it's never wise to assume I know what "the market" does and = doesn't know. If Jeff Garzik is right about what the market has priced = in, then yes, filled blocks will be rocking the boat. But who's to say = that the smartest, biggest investors and traders don't already see this = scaling problem, and have already priced it in? In this case, a sudden = large increase in the block size is actually rocking the boat. The point = is, you can't know either way, so trying to pre-empt the market in this = way is erroneous. >=20 > Regarding entrepreneurial investment specifically, why should we favor = the entrepreneurs who require a more centralized bitcoin over those who = were more considerate of the possibility of rising transaction fees when = making their business models? >=20 > In my mind, we should favor neither, which is why I'm basically in = agreement with Pieter that this sense of "emergency" shouldn't really be = a part of the debate. >=20 > Not that I'm taking a stand on the specific block size issue either = way. I just think this particular line of reasoning (presupposing what = information the market has and has not already baked in) is unsound. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --Apple-Mail=_353D3AD3-5AC9-48E7-8B36-9E33D23E79B8 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 iQIcBAEBCgAGBQJVjgfsAAoJEJNAI64YFENU8ScP/0KpPVF2JD57G/rU5MjqNlhQ YP3P9asU3YjSnyPTbdq2e9UTpwWgWfHJ4Xtcu4S1K/Pmh5D0l1zai5AYW+mm4R72 UzNfMDobkIvq2gDXE5kenlbfV9fDcyk8i8R0O8IsE7OmjIeyJ/9Y8uqcWWPJIxgG MSq0hdhOmebc8WkkqWw6ktMTif11wGe+AO/MaqOVVGwIi0rrS87SW54aD2BPS1p8 pAZOQXy9+kLsGioYzNejJlEZI2XLTHxR5WoqITUUDrIsotrOPeZb6va32u2Y0RcH RKAPXxPNaFMVWBQkZBRWOPMkohKOni94lE8NPBVT2T9dJHJextUB+Dc64tTzJSyE KhVqmEeqgOV+5k1Cs/ypA6CSd51fbigJ0N29jsk1LYiiszvwEPSTdf8sNgYbJokN GhUQ6AzEoNCpDf1r+o75oSjkMOMlcefN6m6FtTypDH6TBosO92aZh/uNI4V7/mJ1 BJ/xSYwtP1+Oe5IcUOMMP+41ODFjIOXp1Pe/A24BwHtoDVAKga5VaYJi4ESwdPbb C/sZnvz2jJK8PveS+6gqV9gojbRiRmm9poXUMqZZSDTAPsEzE+25+OUk56plyTKj 6t42ymmhRlcYSVUzOUg3WTCbpm34qvHAJa2pCoysaLTjSOU0jrUH9smxMzep6U9T Y0KAOvDhLTC6l7ROucp1 =D8/a -----END PGP SIGNATURE----- --Apple-Mail=_353D3AD3-5AC9-48E7-8B36-9E33D23E79B8--