path: root/aa/9de04b206332df935d893a8062a10985c18f4a

Return-Path: <elliot.olds@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 81BB68D3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  6 Aug 2015 23:09:52 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f177.google.com (mail-ig0-f177.google.com
	[209.85.213.177])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BEC28153
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  6 Aug 2015 23:09:50 +0000 (UTC)
Received: by igbij6 with SMTP id ij6so21018397igb.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 06 Aug 2015 16:09:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=DLO1RTjTqnDQyMtVwx5i+R+DoGRf0h2MyTd5/J0zSYY=;
	b=0lTonyVvnyshbYKXyt6vynXPu9kMCX8oVe7QJiu212JpAHn9CNiG8aacaQBuiZDcUx
	9Jwm2wn8Qjn7tyRTmzNiZTgRWwd3CLmiVOM0BPBuILyEAjSurr910XF/Z7Q/BoNPWq8D
	c49HmHJ6lk10x4F3cy+qEEvokHjZYzjB02xLmsCeDgIZjnz/PQ/HmVgElQCKVJr96dfA
	Qs1SsioKDR8Mj76zCxbfChGtpvsvTh/hrT9jdGk0VeKz9Pa1frYRF/pyITgpGcvQU29j
	38BJM1pgVcUaMxy1IA+34ZK3lI1Xex4In01ErdBwdMX/PZg0HU4l8jkalSYuM61uvaVn
	+nqw==
MIME-Version: 1.0
X-Received: by 10.50.25.226 with SMTP id f2mr295615igg.87.1438902590277; Thu,
	06 Aug 2015 16:09:50 -0700 (PDT)
Received: by 10.79.97.4 with HTTP; Thu, 6 Aug 2015 16:09:49 -0700 (PDT)
In-Reply-To: <CABm2gDoNbhc1=kgc0F+wSm33hTmRmmptk-XcaZxsm=6iJkWu=w@mail.gmail.com>
References: <CAPg+sBj-wA1DMrwkQRWnzQoB5NR-q=2-5=WDAAUYfSpXRZSTqw@mail.gmail.com>
	<CABsx9T1NqBX9Tr8vRCtCeri76e0wrtkvRhEPyG9Advv_3Uqxng@mail.gmail.com>
	<CAPg+sBjwVxYTOn3+bwahHGSGpBh5BCh5b4OOFkw_2x97YZSFPQ@mail.gmail.com>
	<CA+w+GKS_wDDgf=HjPgD5QZ_wdTRg7i_oYUgBRmh9HpufETAP=w@mail.gmail.com>
	<CABm2gDqvpWdHdjo1OBzbw-6ivu5DEGcfvK8duc3-KAjsSeWapA@mail.gmail.com>
	<CA+w+GKRPPcgCO0pBP2PjKGU49tWuBoF1vRJzY+4fWn71HOVDPw@mail.gmail.com>
	<CABm2gDqV1NdHJZBmUWX3AxVYy6ErU7AB-wsWgGzbiTL1twdq6g@mail.gmail.com>
	<CA+w+GKTLBWj6b4ppwrmnXb_gybYFcrX7haLBSdCnMaijy2An4w@mail.gmail.com>
	<CABm2gDpWPhYNh=g-ZXCsfe-aPq=N6NKSWKP9kr-KtPVrWAxB7Q@mail.gmail.com>
	<CAAO2FKHsczkwwqO87cJFtxBp9JE=vf=GcxLx37GpRUkPq8VGHQ@mail.gmail.com>
	<CABm2gDpp5+hkHmd6op6PPW658siKoEMRDfTWiEHHM7vJSLDhyA@mail.gmail.com>
	<CA+BnGuFNOjzLaiPPnUSi-rkU94UMgmP30Si8N3oBSYG0q8j-_w@mail.gmail.com>
	<CABm2gDoNbhc1=kgc0F+wSm33hTmRmmptk-XcaZxsm=6iJkWu=w@mail.gmail.com>
Date: Thu, 6 Aug 2015 16:09:49 -0700
Message-ID: <CA+BnGuE1bcFaL70+dvsRgtZib2t+Ogku3rfPSwV-2qjRAVdEcA@mail.gmail.com>
From: Elliot Olds <elliot.olds@gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=047d7bd75b40c29028051cac9d10
X-Spam-Status: No, score=0.9 required=5.0 tests=BAYES_40,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_LOW, URIBL_BLACK autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Block size following technological growth
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, 06 Aug 2015 23:09:52 -0000

--047d7bd75b40c29028051cac9d10
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Aug 5, 2015 at 6:26 PM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote:
>
>
> Given that for any non-absurdly-big size some transactions will
> eventually be priced out, and that the consensus rule serves for
> limiting mining centralization (and more indirectly centralization in
> general) and not about trying to set a given average transaction fee,
> I think the current level of mining centralization will always be more
> relevant than the current fee level when discussing any change to the
> consensus rule to limit centralization (at any point in time).
> In other words, the question "can we change this without important
> risks of destroying the decentralized properties of the system in the
> short or long run?" should be always more important than "is there a
> concerning rise in fees to motivate this change at all?".
>

I agree with you that decentralization is the most important feature of
Bitcoin, but I also think we need to think probabilistically and concretely
about when risks to decentralization are worthwhile.

Decentralization is not infinitely valuable in relation to low fees, just
like being alive is not infinitely valuable in relation to having money.
For instance, people will generally not accept a 100% probability of death
in exchange for any amount of money. However anyone who understands
probability and has the preferences of a normal person would play a game
where they accept a one in a billion chance of instant death to win one
billion dollars if they don't die.

Similarly we shouldn't accept a 100% probability of Bitcoin being
controlled by a single entity for any guarantee of cheap tx fees no matter
how low they are, but there should be some minuscule risk of
decentralization that we'd be willing to accept (like raising the block
size to 1.01 MB) if it somehow allowed us to dramatically increase
usability. (Imagine something like the Lightning Network but even better
was developed, but it could only work with 1.01 MB blocks).



> > Jorge, if a fee equilibrium developed at 1MB of $5/tx, and you somehow
> knew
> > with certainty that increasing to 4MB would result in a 20 cent/tx
> > equilibrium that would last for a year (otherwise fees would stay aroun=
d
> $5
> > for that year), would you be in favor of an increase to 4MB?
>
> As said, I would always consider the centralization risks first: I'd
> rather have a $5/tx decentralized Bitcoin than a Bitcoin with free
> transactions but effectively validated (when they validate blocks they
> mine on top of) by around 10 miners, specially if only 3 of them could
> easily collude to censor transactions [orphaning any block that
> doesn't censor in the same manner]. Sadly I have no choice, the later
> is what we have right now. And reducing the block size can't guarantee
> that the situation will get better or even that fees could rise to
> $5/tx (we just don't have that demand, not that it is a goal for
> anyone). All I know is that increasing the block size *could*
> (conditional, not necessarily, I don't know in which cases, I don't
> think anybody does) make things even worse.
>

I agree that we don't have good data about what exactly a 4 MB increase
would do. It sounds like you think the risks are too great / uncertain to
move from 1 MB to 4 MB blocks in the situation I described. I'm not clear
though on which specific risks you'd be most worried about at 4 MB, and if
there are any risks that you think don't matter at 4 MB but that you would
be worried about at higher block size levels. I also don't know if we have
similar ideas about the benefits of low tx fees. If we discussed exactly
how we were evaluating this scenario, maybe we'd discover that something I
thought was a huge benefit of low tx fees is actually not that compelling,
or maybe we'd discover that our entire disagreement boiled down to our
estimate of one specific risk.

For the record, I think these are the main harms of $5 tx fees, along with
the main risks I see from moving to 4 MB:

Fees of $5/tx would:
(a) Prevent a lot of people who could otherwise benefit from Bitcoin's
decentralization from having an opportunity to reap those benefits.
Especially people in poor countries with corrupt governments who could get
immediate benefit from it now.
(b) Prevent developers from experimenting with new Bitcoin use-cases, which
might eventually lead to helpful services.
(c) Prevent regular people from using Bitcoin and experimenting with it and
getting involved, because they think it's unusable for txns under many
hundreds of dollars in value, so it doesn't interest them. Not having the
public on our side could make us more vulnerable to regulators.

Changing the block size to 4 MB would:
(1) Probably reduce the number of full nodes by around 5%. Most of the drop
in full nodes over the past few years is probably due to Bitcoin Core being
used by fewer regular users for convenience reasons, but the extra HD space
required and extra bandwidth would probably make some existing people
running full nodes stop.
(2) Not hinder low bandwidth miners significantly, because of the relay
network.
(3) Not introduce any tx verification issues, because processors are fast
and tx processing is ridiculously cheap and we'd need way more than 4 MB of
txs for it to be a bottleneck.

So (1) is the only risk that gives me any significant concern, but I don't
think that the number of full nodes now is at a dangerous level.

Anyway, the point isn't for you and I to actually discuss this particular
hypothetical in more detail (although I would be curious to see similar
lists from you). I haven't studied the risks enough to actually put this
forth to the list as a good argument for what to do in this situation. My
main point is that being very specific and concrete both about our thought
process and about the hypothetical situation results in much better
discussions.

There's one more piece of information that I can give you which will help
you understand my position much better, and also force me to think really
carefully about this. It's the point at which I would switch to the other
side of the argument (either by varying the tx fee, or the block size). If
tx fees would only rise to 60 cents or lower if we stayed at 1 MB, then I
would be against a move to 4 MB. Or, keeping the hypothetical 1 MB fee at
$5, I think moving to 12 MB or higher is the point at which I'd switch over
to being a 1 MB advocate. Getting that same info from you tells me exactly
how you weigh the risks in a way that just listing the factors can't. In
this specific hypothetical scenario, what is the lowest block size increase
that you'd accept? It can be extremely low, like 1.01 MB. If you tell me
that you'd rather have $5 tx fees for the next year instead of changing the
block size to 1.01 MB, I would be really surprised.

Gavin is the only other person who I've seen who has defined at what block
size he'd switch to the other side (maybe not with a concrete number, but
with a rough range: the block size such that a normal person with a pretty
good connection couldn't run a full node).


> On the other hand, I could understand people getting worried if fees
> where as high as $5/tx or even 20 cent/tx but we're very far away from
> that case. How can low subsidies (a certainty) be "too far in the
> future to worry about it" but $5/tx, 20 cent/tx or even 5 cent/tx an
> urgent concern?


I would say that in this case we know high tx fees could happen very soon
because there is a clear mechanism. Bitcoin just needs to become more
popular quickly for any number of reasons. Suppose the infrastructure for
remittances starts falling into place within the next two months, and
suddenly immigrants are clamoring to use Bitcoin to send money back to
their home countries. This could result in $5 tx fees very soon (not that I
think it's likely). Many of these immigrants would still use Bitcoin
because it's still better than the alternative for remittances, which would
price out a lot of people currently using Bitcoin for other reasons. As far
as I know, there is no plausible way that subsidies could plummet in
anywhere near that time frame, aside from the price of Bitcoin completely
collapsing. But if that happens in the near term (specifically, with very
low tx volume) a fee market won't help.


> For all I know, 5 cent/tx may not happen in the next
> 25 years: it may never happen. And if it happens, to me it will be a
> symptom of Bitcoin success, even for others it means that Bitcoin has
> become a "high value settlement network".
>

I would be extremely happy if Bitcoin could somehow sustain itself in the
long run with 5 cent tx fees. I'm optimistic about Lightning to handle the
cases where people need even cheaper txns.



> I'm still missing an answer from the "big blocks size side" to the
> following question (which I have insistently repeated with various
> permutations):
>
> If "not now" when will it be a good time to let fees rise above zero?
> After the next subsidy halving? After 4 more subsidy halvings (ie
> about 13 years from now, subsidy =3D 1.5625 btc/block )? After your
> grandmother abandons her national currency and uses Bitcoin for
> everything? Never?
>
> ANY answer (maybe with the exception of the last one) would be less
> worrying than silence.
>

Before I answer, here's my reasoning about why we don't need to worry about
a fee market now:

There is nothing particularly special about a fee market in Bitcoin. We
know how markets work, and we have no reason to suspect a fee market in
Bitcoin will have any new properties of markets that we can't foresee. When
demand becomes higher, there will be some equilibrium level of fee that
people have to pay to give a certain probability of inclusion within a
certain number of blocks. There will likely be some level of fee where if
you don't pay it, your tx will never be confirmed.

We have seen something like this working at various points in Bitcoin's
history. Look at the recent "stress tests." To get your tx confirmed in a
reasonable time frame, you had to bump your fee a little higher than the
txns from whoever was flooding the network. If you did, everything worked
fine. If you didn't, your tx didn't confirm (until the test ended, maybe?).
So there's nothing complicated here. It doesn't require a decade long
preparation to prove to ourselves that a fee market will work.

Unless in the future mining is funded mostly by charity (I think there's
only a 25% chance of that happening), we will need a fee market eventually.
I'd be fine if one developed now. I think 10 cents per txn right now
wouldn't be too bad, aside from the following reason. What concerns me
about insisting on a fee market right now is that usage is so small and the
block size is so limited that if demand increases just a little bit, fees
could skyrocket. It's not the 10 cent fees that would worry me, but what
they say about the potential for a huge spike. Fees could become $10 per tx
or higher very quickly. Yes, that would show that big organizations find
Bitcoin useful which is nice, but it'd also put decentralized money out of
reach of many other people. While Bitcoin still has a lot of growth ahead
of it, it's better to not set up roadblocks (for reasons other than
preserving decentralization) in front of that growth which will make things
very painful if that growth happens more suddenly than we expect.

I think the best argument for having a fee market right now is that if we
move to such a market suddenly in the future, wallets won't have time to
make the user experience good, and full nodes might not be written in such
a way that they gracefully handle a bunch of txns that might never confirm.
I don't think the required software changes are that complex though, so it
seems unnecessary to start adding friction for users now for something that
might be an issue in 10+ years.

So to answer your question: about two years before we think Bitcoin will
need to rely heavily on txn fees for security, I'd be in favor of adjusting
block size so that it resulted in enough total fees / security. Until that
point, we should care a lot about Bitcoin being widely used so that when we
do need a fee market, it's more like lots of people paying 5 cents per tx
instead of fewer people paying $10/tx. I think the former situation is much
more likely to sustainable, and we're more likely to get there if we
encourage low fee use cases now.

You've been arguing that 0 fee transactions will have to disappear someday,
but this isn't necessarily true. As long as enough people care about having
their txns confirm relatively quickly, there's no reason to make sure that
people who pay 0 fees never have their txns confirmed.

--047d7bd75b40c29028051cac9d10
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Aug 5, 2015 at 6:26 PM, Jorge Tim=C3=B3n <span dir=3D"ltr">&lt;<a href=
=3D"mailto:jtimon@jtimon.cc" target=3D"_blank">jtimon@jtimon.cc</a>&gt;</sp=
an> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><span><br>
</span>Given that for any non-absurdly-big size some transactions will<br>
eventually be priced out, and that the consensus rule serves for<br>
limiting mining centralization (and more indirectly centralization in<br>
general) and not about trying to set a given average transaction fee,<br>
I think the current level of mining centralization will always be more<br>
relevant than the current fee level when discussing any change to the<br>
consensus rule to limit centralization (at any point in time).<br>
In other words, the question &quot;can we change this without important<br>
risks of destroying the decentralized properties of the system in the<br>
short or long run?&quot; should be always more important than &quot;is ther=
e a<br>
concerning rise in fees to motivate this change at all?&quot;.<br></blockqu=
ote><div><br></div><div>I agree with you that decentralization is the most =
important feature of Bitcoin, but I also think we need to think probabilist=
ically and concretely about when risks to decentralization are worthwhile.=
=C2=A0</div><div><br></div><div>Decentralization is not infinitely valuable=
 in relation to low fees, just like being alive is not infinitely valuable =
in relation to having money. For instance, people will generally not accept=
 a 100% probability of death in exchange for any amount of money. However a=
nyone who understands probability and has the preferences of a normal perso=
n would play a game where they accept a one in a billion chance of instant =
death to win one billion dollars if they don&#39;t die.=C2=A0</div><div><br=
></div><div>Similarly we shouldn&#39;t accept a 100% probability of Bitcoin=
 being controlled by a single entity for any guarantee of cheap tx fees no =
matter how low they are, but there should be some minuscule risk of decentr=
alization that we&#39;d be willing to accept (like raising the block size t=
o 1.01 MB) if it somehow allowed us to dramatically increase usability. (Im=
agine something like the Lightning Network but even better was developed, b=
ut it could only work with 1.01 MB blocks).</div><div><br></div><div>=C2=A0=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><span>
&gt; Jorge, if a fee equilibrium developed at 1MB of $5/tx, and you somehow=
 knew<br>
&gt; with certainty that increasing to 4MB would result in a 20 cent/tx<br>
&gt; equilibrium that would last for a year (otherwise fees would stay arou=
nd $5<br>
&gt; for that year), would you be in favor of an increase to 4MB?<br>
<br>
</span>As said, I would always consider the centralization risks first: I&#=
39;d<br>
rather have a $5/tx decentralized Bitcoin than a Bitcoin with free<br>
transactions but effectively validated (when they validate blocks they<br>
mine on top of) by around 10 miners, specially if only 3 of them could<br>
easily collude to censor transactions [orphaning any block that<br>
doesn&#39;t censor in the same manner]. Sadly I have no choice, the later<b=
r>
is what we have right now. And reducing the block size can&#39;t guarantee<=
br>
that the situation will get better or even that fees could rise to<br>
$5/tx (we just don&#39;t have that demand, not that it is a goal for<br>
anyone). All I know is that increasing the block size *could*<br>
(conditional, not necessarily, I don&#39;t know in which cases, I don&#39;t=
<br>
think anybody does) make things even worse.<br></blockquote><div><br></div>=
<div>I agree that we don&#39;t have good data about what exactly a 4 MB inc=
rease would do. It sounds like you think the risks are too great / uncertai=
n to move from 1 MB to 4 MB blocks in the situation I described. I&#39;m no=
t clear though on which specific risks you&#39;d be most worried about at 4=
 MB, and if there are any risks that you think don&#39;t matter at 4 MB but=
 that you would be worried about at higher block size levels. I also don&#3=
9;t know if we have similar ideas about the benefits of low tx fees. If we =
discussed exactly how we were evaluating this scenario, maybe we&#39;d disc=
over that something I thought was a huge benefit of low tx fees is actually=
 not that compelling, or maybe we&#39;d discover that our entire disagreeme=
nt boiled down to our estimate of one specific risk.=C2=A0</div><div><br></=
div><div><div><div>For the record, I think these are the main harms of $5 t=
x fees, along with the main risks I see from moving to 4 MB:</div><div><br>=
</div><div>Fees of $5/tx would:</div><div>(a) Prevent a lot of people who c=
ould otherwise benefit from Bitcoin&#39;s decentralization from having an o=
pportunity to reap those benefits. Especially people in poor countries with=
 corrupt governments who could get immediate benefit from it now.=C2=A0</di=
v><div>(b) Prevent developers from experimenting with new Bitcoin use-cases=
, which might eventually lead to helpful services.</div><div>(c) Prevent re=
gular people from using Bitcoin and experimenting with it and getting invol=
ved, because they think it&#39;s unusable for txns under many hundreds of d=
ollars in value, so it doesn&#39;t interest them. Not having the public on =
our side could make us more vulnerable to regulators.=C2=A0</div><div><br><=
/div><div>Changing the block size to 4 MB would:</div><div>(1) Probably red=
uce the number of full nodes by around 5%. Most of the drop in full nodes o=
ver the past few years is probably due to Bitcoin Core being used by fewer =
regular users for convenience reasons, but the extra HD space required and =
extra bandwidth would probably make some existing people running full nodes=
 stop.=C2=A0</div><div>(2) Not hinder low bandwidth miners significantly, b=
ecause of the relay network.</div><div>(3) Not introduce any tx verificatio=
n issues, because processors are fast and tx processing is ridiculously che=
ap and we&#39;d need way more than 4 MB of txs for it to be a bottleneck.</=
div><div><br></div><div>So (1) is the only risk that gives me any significa=
nt concern, but I don&#39;t think that the number of full nodes now is at a=
 dangerous level.</div></div><div><br></div><div>Anyway, the point isn&#39;=
t for you and I to actually discuss this particular hypothetical in more de=
tail (although I would be curious to see similar lists from you). I haven&#=
39;t studied the risks enough to actually put this forth to the list as a g=
ood argument for what to do in this situation. My main point is that being =
very specific and concrete both about our thought process and about the hyp=
othetical situation results in much better discussions.=C2=A0<br></div><div=
><br></div><div>There&#39;s one more piece of information that I can give y=
ou which will help you understand my position much better, and also force m=
e to think really carefully about this. It&#39;s the point at which I would=
 switch to the other side of the argument (either by varying the tx fee, or=
 the block size). If tx fees would only rise to 60 cents or lower if we sta=
yed at 1 MB, then I would be against a move to 4 MB. Or, keeping the hypoth=
etical 1 MB fee at $5, I think moving to 12 MB or higher is the point at wh=
ich I&#39;d switch over to being a 1 MB advocate. Getting that same info fr=
om you tells me exactly how you weigh the risks in a way that just listing =
the factors can&#39;t. In this specific hypothetical scenario, what is the =
lowest block size increase that you&#39;d accept? It can be extremely low, =
like 1.01 MB. If you tell me that you&#39;d rather have $5 tx fees for the =
next year instead of changing the block size to 1.01 MB, I would be really =
surprised.=C2=A0</div><div><br></div><div>Gavin is the only other person wh=
o I&#39;ve seen who has defined at what block size he&#39;d switch to the o=
ther side (maybe not with a concrete number, but with a rough range: the bl=
ock size such that a normal person with a pretty good connection couldn&#39=
;t run a full node).</div><div>=C2=A0<br></div></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">
On the other hand, I could understand people getting worried if fees<br>
where as high as $5/tx or even 20 cent/tx but we&#39;re very far away from<=
br>
that case. How can low subsidies (a certainty) be &quot;too far in the<br>
future to worry about it&quot; but $5/tx, 20 cent/tx or even 5 cent/tx an<b=
r>
urgent concern?</blockquote><div><br></div><div>I would say that in this ca=
se we know high tx fees could happen very soon because there is a clear mec=
hanism. Bitcoin just needs to become more popular quickly for any number of=
 reasons. Suppose the infrastructure for remittances starts falling into pl=
ace within the next two months, and suddenly immigrants are clamoring to us=
e Bitcoin to send money back to their home countries. This could result in =
$5 tx fees very soon (not that I think it&#39;s likely). Many of these immi=
grants would still use Bitcoin because it&#39;s still better than the alter=
native for remittances, which would price out a lot of people currently usi=
ng Bitcoin for other reasons. As far as I know, there is no plausible way t=
hat subsidies could plummet in anywhere near that time frame, aside from th=
e price of Bitcoin completely collapsing. But if that happens in the near t=
erm (specifically, with very low tx volume) a fee market won&#39;t help.</d=
iv><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex"> For all I know, 5 cent/=
tx may not happen in the next<br>
25 years: it may never happen. And if it happens, to me it will be a<br>
symptom of Bitcoin success, even for others it means that Bitcoin has<br>
become a &quot;high value settlement network&quot;.<br></blockquote><div><b=
r></div><div>I would be extremely happy if Bitcoin could somehow sustain it=
self in the long run with 5 cent tx fees. I&#39;m optimistic about Lightnin=
g to handle the cases where people need even cheaper txns.=C2=A0</div><div>=
<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I&#39;m still missing an answer from the &quot;big blocks size side&quot; t=
o the<br>
following question (which I have insistently repeated with various<br>
permutations):<br>
<br>
If &quot;not now&quot; when will it be a good time to let fees rise above z=
ero?<br>
After the next subsidy halving? After 4 more subsidy halvings (ie<br>
about 13 years from now, subsidy =3D 1.5625 btc/block )? After your<br>
grandmother abandons her national currency and uses Bitcoin for<br>
everything? Never?<br>
<br>
ANY answer (maybe with the exception of the last one) would be less<br>
worrying than silence.<br></blockquote><div><br></div><div>Before I answer,=
 here&#39;s my reasoning about why we don&#39;t need to worry about a fee m=
arket now:</div><div><br></div><div>There is nothing particularly special a=
bout a fee market in Bitcoin. We know how markets work, and we have no reas=
on to suspect a fee market in Bitcoin will have any new properties of marke=
ts that we can&#39;t foresee. When demand becomes higher, there will be som=
e equilibrium level of fee that people have to pay to give a certain probab=
ility of inclusion within a certain number of blocks. There will likely be =
some level of fee where if you don&#39;t pay it, your tx will never be conf=
irmed.=C2=A0</div><div><br></div><div>We have seen something like this work=
ing at various points in Bitcoin&#39;s history. Look at the recent &quot;st=
ress tests.&quot; To get your tx confirmed in a reasonable time frame, you =
had to bump your fee a little higher than the txns from whoever was floodin=
g the network. If you did, everything worked fine. If you didn&#39;t, your =
tx didn&#39;t confirm (until the test ended, maybe?). So there&#39;s nothin=
g complicated here. It doesn&#39;t require a decade long preparation to pro=
ve to ourselves that a fee market will work.</div><div><br></div><div>Unles=
s in the future mining is funded mostly by charity (I think there&#39;s onl=
y a 25% chance of that happening), we will need a fee market eventually. I&=
#39;d be fine if one developed now. I think 10 cents per txn right now woul=
dn&#39;t be too bad, aside from the following reason. What concerns me abou=
t insisting on a fee market right now is that usage is so small and the blo=
ck size is so limited that if demand increases just a little bit, fees coul=
d skyrocket. It&#39;s not the 10 cent fees that would worry me, but what th=
ey say about the potential for a huge spike. Fees could become $10 per tx o=
r higher very quickly. Yes, that would show that big organizations find Bit=
coin useful which is nice, but it&#39;d also put decentralized money out of=
 reach of many other people. While Bitcoin still has a lot of growth ahead =
of it, it&#39;s better to not set up roadblocks (for reasons other than pre=
serving decentralization) in front of that growth which will make things ve=
ry painful if that growth happens more suddenly than we expect.=C2=A0</div>=
<div><br></div><div>I think the best argument for having a fee market right=
 now is that if we move to such a market suddenly in the future, wallets wo=
n&#39;t have time to make the user experience good, and full nodes might no=
t be written in such a way that they gracefully handle a bunch of txns that=
 might never confirm. I don&#39;t think the required software changes are t=
hat complex though, so it seems unnecessary to start adding friction for us=
ers now for something that might be an issue in 10+ years.=C2=A0</div><div>=
<br></div><div>So to answer your question: about two years before we think =
Bitcoin will need to rely heavily on txn fees for security, I&#39;d be in f=
avor of adjusting block size so that it resulted in enough total fees / sec=
urity. Until that point, we should care a lot about Bitcoin being widely us=
ed so that when we do need a fee market, it&#39;s more like lots of people =
paying 5 cents per tx instead of fewer people paying $10/tx. I think the fo=
rmer situation is much more likely to sustainable, and we&#39;re more likel=
y to get there if we encourage low fee use cases now.</div><div><br></div><=
div>You&#39;ve been arguing that 0 fee transactions will have to disappear =
someday, but this isn&#39;t necessarily true. As long as enough people care=
 about having their txns confirm relatively quickly, there&#39;s no reason =
to make sure that people who pay 0 fees never have their txns confirmed.=C2=
=A0</div><div>=C2=A0</div></div></div></div>

--047d7bd75b40c29028051cac9d10--