From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <elombrozo@gmail.com> Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 5DAE8273 for <bitcoin-dev@lists.linuxfoundation.org>; Sat, 27 Jun 2015 02:54:51 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 93953108 for <bitcoin-dev@lists.linuxfoundation.org>; Sat, 27 Jun 2015 02:54:50 +0000 (UTC) Received: by padev16 with SMTP id ev16so77270273pad.0 for <bitcoin-dev@lists.linuxfoundation.org>; Fri, 26 Jun 2015 19:54:50 -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=Rr25zCErpr2Oo+Dafp2xSUmCPfWXWZhI4mc5N4bRFhk=; b=ZkCt9S8TCSRE7mjXPjDrhst858DPLJMbLfPySBkr44uvioqPZPYkIY8ezgDzwv0eyA +atI/ErpuyJK++yzp75IC6XkYt++HXQac9i+Q5BeVlhwOnXFtL6Lt66iHSBjmI7KK4pD fwPUGYFZHVPuyH2eDIeZvQO6ysnB/Jye0RVm0/P14+pBepG4Br3Q+t+ixPpxxFBatDWV qadl6bOH51m79NlgBQ3XgrJXURc3HtbMI7L25eGg+VEQ+4sZGTGjfSpZDe4ooOvqQStU GeAHECJMJseKkfiRvYOSEo3b8aTzXQwb5FSRMHdBsGEfOdKZ6YjP02Pr4cP5RG/eIObi CO8w== X-Received: by 10.68.250.194 with SMTP id ze2mr9411923pbc.24.1435373690343; Fri, 26 Jun 2015 19:54:50 -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 eu5sm34985603pac.37.2015.06.26.19.54.38 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 26 Jun 2015 19:54:48 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_FAF2319A-A612-4E0B-9796-E8AE26AC34F8"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Eric Lombrozo <elombrozo@gmail.com> In-Reply-To: <2107342B-1D9E-4575-B7E4-3B69D51B1A17@gmail.com> Date: Fri, 26 Jun 2015 19:54:37 -0700 Message-Id: <2C8D5EFF-AB1E-4003-A264-707CAF7CA1F4@gmail.com> References: <CAPg+sBjOj9eXiDG0F6G54SVKkStF_1HRu2wzGqtFF5X_NAWy4w@mail.gmail.com> <CADm_Wca+ow4pMzN7SyKjsMdFo0wuUerYYjf5xKs5G_2Q2PzMmA@mail.gmail.com> <CAPg+sBg=sn7djO_8H16NDg7S7m7_0eTcrgLVofMWQ2ANz+jw9w@mail.gmail.com> <CADm_WcbQog_UCV=JPHyqTRxKbaGY7jedtHE_D8jJSe_thMg05w@mail.gmail.com> <558DB997.4030209@phauna.org> <2107342B-1D9E-4575-B7E4-3B69D51B1A17@gmail.com> To: Owen Gunden <ogunden@phauna.org> 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 <bitcoin-dev.lists.linuxfoundation.org> List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> X-List-Received-Date: Sat, 27 Jun 2015 02:54:51 -0000 --Apple-Mail=_FAF2319A-A612-4E0B-9796-E8AE26AC34F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I should add that a strategy of =E2=80=9Clet=E2=80=99s avoid fee = pressure as much as possible. let=E2=80=99s avoid even thinking about = how we=E2=80=99ll transition as much as possible.=E2=80=9D strikes me as = at least a tad bit myopic. - Eric Lombrozo > On Jun 26, 2015, at 7:18 PM, Eric Lombrozo <elombrozo@gmail.com> = wrote: >=20 > I=E2=80=99ve been pondering this whole scale issue considerably=E2=80=A6= and 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. >=20 > 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. >=20 > The block size issue is really a usability issue at this point. There = are two fundamental things we need to solve: >=20 > 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.) >=20 > 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. >=20 >=20 >=20 > 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. >=20 >=20 > - Eric Lombrozo >=20 >=20 >> On Jun 26, 2015, at 1:44 PM, Owen Gunden <ogunden@phauna.org> 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 >=20 --Apple-Mail=_FAF2319A-A612-4E0B-9796-E8AE26AC34F8 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 iQIcBAEBCgAGBQJVjhBtAAoJEJNAI64YFENUOX8P/0kUpBTdSGcDdoZDF3CoZefz C4zXfDOuKnOJPemSg9EOpRKSmIZtlBuRhNeikwIZrDTyy9qvxK8AMygr8osDU9Lm 7XJfeG616dKvCihBckZCiNunfNpjzl0fBa9darpva0LQ4V1XaErqi5WtS8m6Jt+s CY4ksKda+TbAbG8lxy1/ed4SgdYcwrYOSv0DP82r7TFcmLR3DDxKEhVzVssczVUg jFdTkPyYf9WRXKOfPsYcTjz7s15ESNSmEjWwygbTee4rZJSweZnOr4CDFte6EdYS CCCo39TXf20ek8siG6Gal0+8/VSLxcdRnQ2+2+TYYMIkBA3ihuwXRkncSo/VaF8y rY4cujWAsA2WZlDqawlQQL3kc0enkGnhs3E/zMP6XxdrkdXzI7DOnpXeMkTKK7w7 eY9ZUgWy1BQ7+8aW/x9lRCuhl50ahYmUU6HooQdqloCL6jiwpDipUYJ9MJVWFBjy oNqQ1m3eadwKPi3K53zOmpp+Yr1PJjBIhoDZgNL7RJpL2qc0VWddYsz0UIBq034c gNHswGbuE4eVaWeQqDIkBFVBrcvM8G1uzkUYD8O745tkAIu0rdFEUb6dH6Y+4uCE IgVq1mgqJfQFZO1VEEGNkY3Wn7YIaniGaLCT7I3Whe6jsXi7qTTkaG8+2pa0gyEL uHMQXuREFBUbJ7/otDBr =6mMo -----END PGP SIGNATURE----- --Apple-Mail=_FAF2319A-A612-4E0B-9796-E8AE26AC34F8--