path: root/9a/588fd2970bde8e7bfda4bfcb2925af053af000

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--