path: root/ec/0bcb0d18d091d7a3b7a47ccde92320d36c1a0c

Return-Path: <will.madden@bridge21inc.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 2650B87A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 20 Aug 2015 14:40:54 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com
	[209.85.213.173])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 88E11118
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 20 Aug 2015 14:40:52 +0000 (UTC)
Received: by igui7 with SMTP id i7so32055705igu.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 20 Aug 2015 07:40:52 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:content-type:mime-version:subject:from
	:in-reply-to:date:cc:message-id:references:to;
	bh=T1KIg7awr8w0042bBrBsKsF8rsnMT0KFHRX23Slvipg=;
	b=VJrP2JS8E4UCywH3s0O/FPsOcVOP8Y2kq2XQzcXyOh2zsmULGDGXSCSlzbZ1HAJTUI
	FcbGdJm10D2Cr0ISJqAPNm95MG+Jw38eYwutiy/3qgePPkOhFW+OAMPTx2/OZKLBTZ2L
	7v23CcnkUYn0NegkW/Dg/0OnRTDDw1Sb0oRu/JIYgnVG7jXdDdo6mtR3lBJzEXmqmM0H
	Glbzge6ToSyjRk8yf9M1OBTbq3F8ldi3dLhBPVkRse7Gj1w0v0NZb5Gr7BbcIq1Sj3x8
	N0LfH+UhzWg/w5zCFdu25gs3Xybhse6ZylHiEbqQRJGUcbEgucBSIqsgSTG4GQ0OF2c8
	oaAg==
X-Gm-Message-State: ALoCoQlBrmLoEoGBReEwdsnZs8l4pr/zPNIZeXZtEWzloA+a39D8VtVwYvOi7QGLcKhhm1M3ZCxd
X-Received: by 10.50.30.36 with SMTP id p4mr7835868igh.87.1440081651946;
	Thu, 20 Aug 2015 07:40:51 -0700 (PDT)
Received: from [192.168.1.86] (c-73-34-122-98.hsd1.co.comcast.net.
	[73.34.122.98])
	by smtp.gmail.com with ESMTPSA id je3sm5014246igb.9.2015.08.20.07.40.50
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Thu, 20 Aug 2015 07:40:51 -0700 (PDT)
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_83ED57C2-34C4-4D68-9DAF-ACFC5A5789C6"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
From: Will Madden <will.madden@bridge21inc.com>
In-Reply-To: <CAPg+sBiwTQNTCBQN_idGGH4yu-mEX-r9QpDoWqR3=iKvMqg4hw@mail.gmail.com>
Date: Thu, 20 Aug 2015 08:40:50 -0600
Message-Id: <166B8CDB-65A9-4183-AACA-5DFECD99C922@bridge21inc.com>
References: <CABsx9T16fH+56isq95m4+QWsKwP==tf75ep8ghnEcBoV4OtZJA@mail.gmail.com>
	<CAPg+sBgOt=qhQVZv5P-4mcD75=L4PKgOfRqhyB6FZdSYQajrwQ@mail.gmail.com>
	<CABsx9T10y6-=c7Qg6jysnf38wRX3NA3wWozxGfE+mEYJvPeqWA@mail.gmail.com>
	<CABm2gDpwMQzju+Gsoe3qMi60MPr7OAiSuigy3RdA1xh-SwFzbw@mail.gmail.com>
	<CABsx9T2aZHe5382_fC7bEG2OFPadS3p0jjaAD8FW7p36XS7tcA@mail.gmail.com>
	<CAPg+sBiwTQNTCBQN_idGGH4yu-mEX-r9QpDoWqR3=iKvMqg4hw@mail.gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
X-Mailer: Apple Mail (2.2102)
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE,
	LOTS_OF_MONEY, 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 <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Fees and the block-finding process
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: Thu, 20 Aug 2015 14:40:54 -0000


--Apple-Mail=_83ED57C2-34C4-4D68-9DAF-ACFC5A5789C6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

>=20
> And if you see Bitcoin as a payment system where guaranteed time to =
confirmation is a feature, I fully agree. But I think that is an =
unrealistic dream. It only seems reliable because of lack of use. It =
costs 1.5 BTC per day to create enough transactions to fill the block =
chain at the minimum relay fee, and a small multiple of that at actual =
fee levels. Assuming that rate remains similar with an increased block =
size, that remains cheap.


Apologies, this is going to be long but please read it...

For starters, f the =E2=80=9Cminimum relay fee=E2=80=9D is 0.0001 BTC, =
and the proven throughput from the recent stress tests was 2.3 =
trx/second, it=E2=80=99s 0.0001 x 2.3 x 60 x 60 x 24 or 19.872 BTC to =
fill up the block chain for 24 hours, not 1.5 BTC.

The math error isn=E2=80=99t important, because the premise of what you =
are saying is based on a misconception.  No one is advocating that we =
should price fix transaction fees at some tiny amount to guarantee cheap =
transactions.  Furthermore, it=E2=80=99s perfectly realistic to believe =
bitcoin can scale reliably without constraining the block size to 1MB, =
given certain constraints.

A quick disclosure, I run a small bitcoin startup that benefits from =
higher bitcoin prices and more people buying bitcoin with their fiat =
currency. I also have an inadvisably high percentage of my remaining =
personal savings denominated in bitcoin.

Back to the point, limiting block size to impose fee pressure is a well =
intentioned idea that is built on a misconception of how bitcoin's =
economics work.  The price of bitcoin is based on the perceived value of =
units inside the protocol. Keeping transaction volumes through the =
bitcoin protocol capped at around 2.3 transactions / second limits the =
number of new people who can use bitcoin to around 100,000 people =
performing a little under 2 transactions daily.  This is only a tiny bit =
more use than where we are presently. It=E2=80=99s forced stagnation.

Please, read and understand: constraining the network affect and =
adoption of bitcoin lowers its overall value, and by extension reduces =
its price as denominated in other currencies.  The only alternatives =
presently to on blockchain transactions are centralized bank ledgers at =
exchanges or similar companies.  Yes, while capping the bitcoin =
max_block_size to a level that restricts use will drive transaction fees =
higher, it will also reduce the underlying price of bitcoin as =
denominated in other currencies, because the outside observer will see =
bitcoin stagnating and failing to grow like a nascent but promising =
technology should.  Higher fees combined with lower bitcoin price =
negates the value of the higher fees, and the only side effect is to =
stymie adoption in the process, while putting more focus on layer =
protocols that are no where near ready for mainstream, stable use! =20

Removing the cap entirely is also a catastrophically poor idea, because =
some group of jerks out there will absolutely make sure that every block =
is 32 MB, making it a real PITA for a hobbyist to get interested in =
bitcoin.  Yes, some miners limit blocksize in order to balance =
propagation times against transaction fee revenue, so there is already a =
mechanism in place to push transaction fees higher by limiting size or =
not including transactions without fees that could offset a spam happy =
bad actor or group of actors, but we cannot leave that to chance.  The =
damage is too high to allow the risk.  Bitcoin is going to grow because =
each new curious, technically savvy kid who learns about it can download =
and participate as a full node.  We=E2=80=99re not anywhere close to =
mainstream adoption or at a level of maturity where the protocol is =
fully baked, so we have an obligation to keep full nodes within the =
grasp of a starving college kid=E2=80=99s budget.  That is the barometer =
here in my mind. =20

40% should be our best guess for keeping bitcoin in reach of hobbyists, =
and safer from more napsteresque node centralization.  It's simple, =
which makes it less prone to failure and being picked apart politically =
as well.  It may be too fast, or it may be too slow, but it=E2=80=99s =
probably a good guess for 5 years, and if history holds true, it will =
work for a long time and make the cost of running a node lower gradually =
as well.  No one can predict the future, but this is the best we have.  =
No one knows if it will be radio propagation of blocks, quantum spin =
liquid based storage or data transmission, or some other breakthrough =
that drives down costs, but something always seems to appear that keeps =
the long term trends intact.  So why wouldn=E2=80=99t we use these =
trends?

8MB is about 40% annually from January 2009 to today.  I can buy a 5TB =
external hard drive right now online for $130.00 in the US.  The true =
block time is just over 9 minutes, so that=E2=80=99s 160 blocks a day x =
8MB x 365.25 days a year, or around 467.52GB of new block size annually. =
 This is 10.69 years of storage for $130.00, or a little over $12 a year =
- which is darn close to what the cost was back in late 2010 when I =
first learned about this stuff...  I fail to see the =E2=80=9Ccentralizati=
on" issue here, and when we contrast $12/year for hobbyists against the =
centralization risks of mining pools, we should all be ashamed to have =
wasted so much energy and time talking about this specific point.  The =
math does not add up, and it=E2=80=99s not a significant centralization =
risk when we put an 8MB cap on this with 40% annual average growth.  The =
energy we=E2=80=99ve blown on this topic should have been put into =
refining privacy, and solving mining pool centralization.  There are so =
many more important problems.

Let's talk about other ideas for a moment.  First, while lightning is =
really cool and I believe it will be an exponential magnifier for =
bitcoin someday, that day is NOT today.  Waiting for layers over bitcoin =
to solve a self-imposed limit of 1mb is just a terrible, horrible idea =
for the health of the protocol.  Lightning is really well thought =
through, but there are still problems that need to be solved.  Forced =
channel expiration, transaction malleability are the theoretical issues =
that must be solved.  There WILL be issues that aren=E2=80=99t =
anticipated and known today when it goes out =E2=80=9Cinto the wild=E2=80=9D=
.  Protocols of this complexity do not go from white paper to stability =
in less than one to two years.  Remember, even the bitcoin reference =
client had a catastrophic bug 1.5 years after its January 2009 launch in =
August 2010.  I read here that the "deepest thinkers" believe we should =
wait for overlays to solve this bottleneck, well, bluntly, that is far =
from practical or pragmatic, and is =E2=80=9Civory tower=E2=80=9D =
thinking.  Discussing approaches like this are worse than agreeing to do =
nothing, because it drains our attention away from other more pressing =
issues that have a time limit on our ability to solve them before the =
protocol crystallizes from the scale of the network effect (like =
privacy, mining centralization, etc.) on top of accomplishing little of =
immediate value other than academic debates.

I=E2=80=99m not winning any popularity contests today=E2=80=A6 but it =
was a bad idea to approach this as we did with XT.  We should have put =
in a solution that addressed just the cap size issue and nothing more.  =
Other changes, pork, and changing the nature of the community management =
around the XT client is just too much political baggage to work without =
fracturing the support of the community.  And guess what happened?  We =
have the major community forum moderators actively censoring posts, =
banning users, and things are looking to the outside observer as if the =
entire system is starting to fall in on itself.  Truth is ladies and =
gentlemen, our egos and economic interests are creating a tragedy of the =
commons that will hurt the lot of us far more than it will help the best =
off of us.  Yeah, I get that no one wants to code in a hostile =
environment, and this community has definitely turned caustic and =
behaves like a mob of petulant children, but sometimes you have to suck =
it up and get things done.=20

So=E2=80=A6 what do we do?  We should get our @#$@ together, stop the =
academic grand standing and ego driven debates, raise the cap to 8mb and =
permit an average growth of 40% a year, then get back to solving real =
problems and working on layer and side chain magnifiers.  Allowing =
bitcoin to grow reasonably allows adoption to spread, the price to rise, =
which creates more demand, higher prices, and more fees.  Again, because =
the fees and coinbase rewards are denominated in bitcoin, this increases =
the return to miners.  This, combined with allowing for growth will =
encourage the price to rise, and increase stability for layers and side =
chains later on down the road when the technology is stable and mature.

For the love of whatever it is you care about, can we please just get =
this done?  Do I have to go brush up on my C++ and start asking everyone =
obnoxious, amateur questions?  Trust me, no one wants that.  Let=E2=80=99s=
 just get the cap raised to 8MB + 40% on average annualized and fight =
viciously about privacy or mining centralization.  Something more =
important. =20

Thanks.


> On Aug 10, 2015, at 8:34 AM, Pieter Wuille via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>=20
> On Mon, Aug 10, 2015 at 4:12 PM, Gavin Andresen =
<gavinandresen@gmail.com <mailto:gavinandresen@gmail.com>> wrote:
>=20
> Executive summary: when networks get over-saturated, they become =
unreliable.  Unreliable is bad.
>=20
> Unreliable and expensive is extra bad, and that's where we're headed =
without an increase to the max block size.
>=20
> I think I see your point of view. You see demand for on-chain =
transactions as a single number that grows with adoption. Once the =
transaction creation rate grows close to the capacity, transactions will =
become unreliable, and you consider this a bad thing.
>=20
> And if you see Bitcoin as a payment system where guaranteed time to =
confirmation is a feature, I fully agree. But I think that is an =
unrealistic dream. It only seems reliable because of lack of use. It =
costs 1.5 BTC per day to create enough transactions to fill the block =
chain at the minimum relay fee, and a small multiple of that at actual =
fee levels. Assuming that rate remains similar with an increased block =
size, that remains cheap.
>=20
> If you want transactions to be cheap, it will also be cheap to make =
them unreliable.
>=20
> --=20
> Pieter
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


--Apple-Mail=_83ED57C2-34C4-4D68-9DAF-ACFC5A5789C6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><div class=3D""><blockquote type=3D"cite" class=3D""><div =
dir=3D"ltr" class=3D""><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><div class=3D"gmail_quote"><br class=3D"">And if =
you see Bitcoin as a payment system where guaranteed time to =
confirmation is a feature, I fully agree. But I think that is an =
unrealistic dream. It only seems reliable because of lack of use. It =
costs 1.5 BTC per day to create enough transactions to fill the block =
chain at the minimum relay fee, and a small multiple of that at actual =
fee levels. Assuming that rate remains similar with an increased block =
size, that remains cheap.<br =
class=3D""></div></div></div></div></blockquote></div><div class=3D""><br =
class=3D""></div><div class=3D"">Apologies, this is going to be long but =
please read it...</div><div class=3D""><br class=3D""></div><div =
class=3D"">For starters, f the =E2=80=9Cminimum relay fee=E2=80=9D is =
0.0001 BTC, and the proven throughput from the recent stress tests was =
2.3 trx/second, it=E2=80=99s 0.0001 x 2.3 x 60 x 60 x 24 or 19.872 BTC =
to fill up the block chain for 24 hours, not 1.5 BTC.</div><div =
class=3D""><br class=3D""></div><div class=3D"">The math error isn=E2=80=99=
t important, because the premise of what you are saying is based on a =
misconception. &nbsp;No one is advocating that we should price fix =
transaction fees at some tiny amount to guarantee cheap transactions. =
&nbsp;Furthermore, it=E2=80=99s perfectly realistic to believe bitcoin =
can scale reliably without constraining the block size to 1MB, given =
certain constraints.</div><div class=3D""><br class=3D""></div><div =
class=3D"">A quick disclosure, I run a small bitcoin startup that =
benefits from higher bitcoin prices and more people buying bitcoin with =
their fiat currency. I also have an inadvisably high percentage of my =
remaining personal savings denominated in bitcoin.</div><div =
class=3D""><br class=3D""></div><div class=3D"">Back to the point, =
limiting block size to impose fee pressure is a well intentioned idea =
that is built on a misconception of how bitcoin's economics work. =
&nbsp;The price of bitcoin is based on the perceived value of units =
inside the protocol. Keeping transaction volumes through the bitcoin =
protocol capped at around 2.3 transactions / second limits the number of =
new people who can use bitcoin to around 100,000 people performing a =
little under 2 transactions daily. &nbsp;This is only a tiny bit more =
use than where we are presently. It=E2=80=99s forced =
stagnation.</div><div class=3D""><br class=3D""></div><div =
class=3D"">Please, read and understand: constraining the network affect =
and adoption of bitcoin lowers its overall value, and by extension =
reduces its price as denominated in other currencies. &nbsp;The only =
alternatives presently to on blockchain transactions are centralized =
bank ledgers at exchanges or similar companies. &nbsp;Yes, while capping =
the bitcoin max_block_size to a level that restricts use will drive =
transaction fees higher, it will also reduce the underlying price of =
bitcoin as denominated in other currencies, because the outside observer =
will see bitcoin stagnating and failing to grow like a nascent but =
promising technology should. &nbsp;Higher fees combined with lower =
bitcoin price negates the value of the higher fees, and the only side =
effect is to stymie adoption in the process, while putting more focus on =
layer protocols that are no where near ready for mainstream, stable use! =
&nbsp;</div><div class=3D""><br class=3D""></div><div class=3D"">Removing =
the cap entirely is also a catastrophically poor idea, because some =
group of jerks out there will absolutely make sure that every block is =
32 MB, making it a real PITA for a hobbyist to get interested in =
bitcoin. &nbsp;Yes, some miners limit blocksize in order to balance =
propagation times against transaction fee revenue, so there is already a =
mechanism in place to push transaction fees higher by limiting size or =
not including transactions without fees that could offset a spam happy =
bad actor or group of actors, but we cannot leave that to chance. =
&nbsp;The damage is too high to allow the risk. &nbsp;Bitcoin is going =
to grow because each new curious, technically savvy kid who learns about =
it can download and participate as a full node. &nbsp;We=E2=80=99re not =
anywhere close to mainstream adoption or at a level of maturity where =
the protocol is fully baked, so we have an obligation to keep full nodes =
within the grasp of a starving college kid=E2=80=99s budget. &nbsp;That =
is the barometer here in my mind. &nbsp;</div><div class=3D""><br =
class=3D""></div><div class=3D"">40% should be our best guess for =
keeping bitcoin in reach of hobbyists, and safer from more napsteresque =
node centralization. &nbsp;It's simple, which makes it less prone to =
failure and being picked apart politically as well. &nbsp;It may be too =
fast, or it may be too slow, but it=E2=80=99s probably a good guess for =
5 years, and if history holds true, it will work for a long time and =
make the cost of running a node lower gradually as well. &nbsp;No one =
can predict the future, but this is the best we have. &nbsp;No one knows =
if it will be radio propagation of blocks, quantum spin liquid based =
storage or data transmission, or some other breakthrough that drives =
down costs, but something always seems to appear that keeps the long =
term trends intact. &nbsp;So why wouldn=E2=80=99t we use these =
trends?</div><div class=3D""><br class=3D""></div><div class=3D"">8MB is =
about 40% annually from January 2009 to today. &nbsp;I can buy a 5TB =
external hard drive right now online for $130.00 in the US. &nbsp;The =
true block time is just over 9 minutes, so that=E2=80=99s 160 blocks a =
day x 8MB x 365.25 days a year, or around 467.52GB of new block size =
annually. &nbsp;This is 10.69 years of storage for $130.00, or a little =
over $12 a year - which is darn close to what the cost was back in late =
2010 when I first learned about this stuff... &nbsp;I fail to see the =
=E2=80=9Ccentralization" issue here, and when we contrast $12/year for =
hobbyists against the centralization risks of mining pools, we should =
all be ashamed to have wasted so much energy and time talking about this =
specific point. &nbsp;The math does not add up, and it=E2=80=99s not a =
significant centralization risk when we put an 8MB cap on this with 40% =
annual average growth. &nbsp;The energy we=E2=80=99ve blown on this =
topic should have been put into refining privacy, and solving mining =
pool centralization. &nbsp;There are so many more important =
problems.</div><div class=3D""><br class=3D""></div><div class=3D"">Let's =
talk about other ideas for a moment. &nbsp;First, while lightning is =
really cool and I believe it will be an exponential magnifier for =
bitcoin someday, that day is NOT today. &nbsp;Waiting for layers over =
bitcoin to solve a self-imposed limit of 1mb is just a terrible, =
horrible idea for the health of the protocol. &nbsp;Lightning is really =
well thought through, but there are still problems that need to be =
solved. &nbsp;Forced channel expiration, transaction malleability are =
the theoretical issues that must be solved. &nbsp;There WILL be issues =
that aren=E2=80=99t anticipated and known today when it goes out =E2=80=9C=
into the wild=E2=80=9D. &nbsp;Protocols of this complexity do not go =
from white paper to stability in less than one to two years. =
&nbsp;Remember, even the bitcoin reference client had a catastrophic bug =
1.5 years after its January 2009 launch in August 2010. &nbsp;I read =
here that the "deepest thinkers" believe we should wait for overlays to =
solve this bottleneck, well, bluntly, that is far from practical or =
pragmatic, and is =E2=80=9Civory tower=E2=80=9D thinking. =
&nbsp;Discussing approaches like this are worse than agreeing to do =
nothing, because it drains our attention away from other more pressing =
issues that have a time limit on our ability to solve them before the =
protocol crystallizes from the scale of the network effect (like =
privacy, mining centralization, etc.) on top of accomplishing little of =
immediate value other than academic debates.</div><div class=3D""><br =
class=3D"">I=E2=80=99m not winning any popularity contests today=E2=80=A6 =
but it was a bad idea to approach this as we did with XT. &nbsp;We =
should have put in a solution that addressed just the cap size issue and =
nothing more. &nbsp;Other changes, pork, and changing the nature of the =
community management around the XT client is just too much political =
baggage to work without fracturing the support of the community. =
&nbsp;And guess what happened? &nbsp;We have the major community forum =
moderators actively censoring posts, banning users, and things are =
looking to the outside observer as if the entire system is starting to =
fall in on itself. &nbsp;Truth is ladies and gentlemen, our egos and =
economic interests are creating a tragedy of the commons that will hurt =
the lot of us far more than it will help the best off of us. &nbsp;Yeah, =
I get that no one wants to code in a hostile environment, and this =
community has definitely turned caustic and behaves like a mob of =
petulant children, but sometimes you have to suck it up and get things =
done.&nbsp;<br class=3D""><br class=3D"">So=E2=80=A6 what do we do? =
&nbsp;We should get our @#$@ together, stop the academic grand standing =
and ego driven debates, raise the cap to 8mb and permit an average =
growth of 40% a year, then get back to solving real problems and working =
on layer and side chain magnifiers. &nbsp;Allowing bitcoin to grow =
reasonably allows adoption to spread, the price to rise, which creates =
more demand, higher prices, and more fees. &nbsp;Again, because the fees =
and coinbase rewards are denominated in bitcoin, this increases the =
return to miners. &nbsp;This, combined with allowing for growth will =
encourage the price to rise, and increase stability for layers and side =
chains later on down the road when the technology is stable and =
mature.<br class=3D""><br class=3D"">For the love of whatever it is you =
care about, can we please just get this done? &nbsp;Do I have to go =
brush up on my C++ and start asking everyone obnoxious, amateur =
questions? &nbsp;Trust me, no one wants that. &nbsp;Let=E2=80=99s just =
get the cap raised to 8MB + 40% on average annualized and fight =
viciously about privacy or mining centralization. &nbsp;Something more =
important. &nbsp;</div><div class=3D""><br class=3D""></div><div =
class=3D"">Thanks.</div><div class=3D""><br class=3D""></div><br =
class=3D""><div><blockquote type=3D"cite" class=3D""><div class=3D"">On =
Aug 10, 2015, at 8:34 AM, Pieter Wuille via bitcoin-dev &lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" =
class=3D"">On Mon, Aug 10, 2015 at 4:12 PM, Gavin Andresen <span =
dir=3D"ltr" class=3D"">&lt;<a href=3D"mailto:gavinandresen@gmail.com" =
target=3D"_blank" class=3D"">gavinandresen@gmail.com</a>&gt;</span> =
wrote:<br class=3D""><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class=3D""><div =
dir=3D"ltr" class=3D"">Executive summary: when networks get =
over-saturated, they become unreliable.&nbsp; Unreliable is bad.<div =
class=3D"gmail_extra"><br class=3D""></div><div =
class=3D"gmail_extra">Unreliable and expensive is extra bad, and that's =
where we're headed without an increase to the max block =
size.</div></div></blockquote><div class=3D""><br class=3D""></div><div =
class=3D"">I think I see your point of view. You see demand for on-chain =
transactions as a single number that grows with adoption. Once the =
transaction creation rate grows close to the capacity, transactions will =
become unreliable, and you consider this a bad thing.<br class=3D""><br =
class=3D""></div><div class=3D"gmail_quote">And if you see Bitcoin as a =
payment system where guaranteed time to confirmation is a feature, I =
fully agree. But I think that is an unrealistic dream. It only seems =
reliable because of lack of use. It costs 1.5 BTC per day to create =
enough transactions to fill the block chain at the minimum relay fee, =
and a small multiple of that at actual fee levels. Assuming that rate =
remains similar with an increased block size, that remains cheap.<br =
class=3D""><br class=3D""></div><div class=3D"gmail_quote">If you want =
transactions to be cheap, it will also be cheap to make them =
unreliable.<br class=3D""><br class=3D"">-- <br class=3D""></div><div =
class=3D"gmail_quote">Pieter<br class=3D""><br =
class=3D""></div></div></div></div>
_______________________________________________<br class=3D"">bitcoin-dev =
mailing list<br class=3D""><a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a><br =
class=3D"">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
br class=3D""></div></blockquote></div><br class=3D""></body></html>=

--Apple-Mail=_83ED57C2-34C4-4D68-9DAF-ACFC5A5789C6--