path: root/22/0aa35fcfeab5635e1a9affb5472dc1389e7ec8

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 BCCFA4D3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 11 Aug 2015 05:48:19 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com
	[209.85.213.176])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 01D8B106
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 11 Aug 2015 05:48:17 +0000 (UTC)
Received: by igbjg10 with SMTP id jg10so15365923igb.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 10 Aug 2015 22:48:17 -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=PmZPoURKcZPEtILMz1n565kRUsfkIZQWk/MSrQrDjpQ=;
	b=s4xOpc+tyTGxBNtf/5MlNCSocpNSg0DR7d4MENvNP/PCyKR8Rl4cW60bT3gpjEvylI
	OLMdrhW0hklS0TttnLuTr1pk2+L7Jx/Jj/nriV24pI806di45mAxJpRlaBgWf2izc7mK
	MNx0wxaseuT7C8gufxrXagSQ7I+6Yq2ywMk5mHSEaOAbOhuK58k+LUwRHyVkVPgmNXHH
	1TFajHAIhLeUmJcwcteBpzZyVgq90xDWsaklokSSVsU9/KZrqWt0R7Ydyp77Y0OZV36a
	Lrw6Y+c0XPWs9Y6wVr034QKinX19LPVVbrzqMl588LrO4szXGzPj2m/UXWLwXT+dBEi3
	cxZg==
MIME-Version: 1.0
X-Received: by 10.50.78.98 with SMTP id a2mr12510884igx.87.1439272097452; Mon,
	10 Aug 2015 22:48:17 -0700 (PDT)
Received: by 10.79.97.135 with HTTP; Mon, 10 Aug 2015 22:48:17 -0700 (PDT)
In-Reply-To: <CABm2gDpGVpb+ZYF-Cg_dFM5aoCM5mADvM5dUqKBmGX_1P6=76A@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>
	<CA+BnGuE1bcFaL70+dvsRgtZib2t+Ogku3rfPSwV-2qjRAVdEcA@mail.gmail.com>
	<CABm2gDpGVpb+ZYF-Cg_dFM5aoCM5mADvM5dUqKBmGX_1P6=76A@mail.gmail.com>
Date: Mon, 10 Aug 2015 22:48:17 -0700
Message-ID: <CA+BnGuG8MJtd0PmHBqvad=Ni8U9VNu083U8K2+obzqngjPTEaw@mail.gmail.com>
From: Elliot Olds <elliot.olds@gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=089e0122edba1a98ea051d02a62c
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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: timon@jtimon.cc
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: Tue, 11 Aug 2015 05:48:19 -0000

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

On Mon, Aug 10, 2015 at 12:28 PM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote=
:

> I would just like that there was an attempt to automatically
> estimate those risks before taking those risks.
>

I agree.


> My main point about fees is that minimum mining fees rising above zero
> (theri current level) is not necessarily a bad thing or an urgent
> concern.
>

Yes, it only gets bad when fees become "high."

I'll skip over the discussion of the pros/cons I listed since that mostly
appeared for illustrative purposes and I don't have a strong disagreement
with anything you said.


> Great. I don't think that minimum mining fees will rise above 1 usd
> cent/tx anytime soon even if we maintain the limit of 1MB.
> Maybe that's why I'm not worried at all about "hitting the limit".
>

My sense is that the people arguing for a hard fork now tend to envision
"hitting the limit" as tx fees being fairly high, and those arguing against
a hard fork envision tx fees staying low when 1 MB blocks start to get
full. Which of those occurs depends on how quickly and in what manner
Bitcoin gains popularity. Even if I thought there's an 95% chance that
there would be no sudden jump in Bitcoin tx demand, I would want to have
some rough plan in place for that other 5% when some previously difficult
use case becomes viable and demand spikes. Do those arguing for the "wait
and see" approach not think that a quick increase in demand is even likely
enough to warrant discussing what we'd do in that case? Greg Maxwell
mentioned doubling the max block size if there was ever a standing backlog =
(
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/007880.html
-- I think fee level is a better metric than size of tx backlog), but I
haven't seen other devs comment on it.


> But I'm sorry, I don't have those concrete numbers because it is a
> trade-off I don't think we've studied in enough detail.
>

The question is about what you'd do in the absence of those details that
you don't have. Imagine that fees spiked to $5/tx tomorrow. You have some
model of the situation that allows you to say that 1.01 MB is something
you'd support, and that's the model that I'm trying to understand. The
answers I gave are not ones I'm confident about. I'm sure if I studied this
for a week they'd change. I sense that devs are reluctant to answer this
question because it could be taken out of context or held against them
later. Or maybe they just don't like saying things that they don't have a
high level of confidence about on principle. IMO this reluctance
contributes to a lack of understanding of each other's positions. We all
have these imperfect models in our heads that we're basing our
disagreements on, but we won't show each other these models.


> > 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, b=
ut
> > with a rough range: the block size such that a normal person with a
> pretty
> > good connection couldn't run a full node).
>
> That would be interesting to read and I have totally missed it.
> Do you have a link?


Sorry, I see how what I wrote was misleading. You've seen the email I'm
referring to. I was talking about when he defined the criteria he used
qualitatively and suggested that's how he arrived at 20 MB:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/009971.h=
tml.
I think he talks about it in a little more detail elsewhere. I inferred
from that that he wouldn't support 40 MB or 80 MB, but that may be wrong.

I should also have given credit to Pieter, as he even more explicitly
specified a level where he'd turn into a hard fork advocate, via his own
hard fork proposal. Neither of these statements specifies exactly where the
switch-over point is, but they're the closest I've seen.


> > I would say that in this case we know high tx fees could happen very so=
on
> > because there is a clear mechanism. Bitcoin just needs to become more
> > popular quickly for any number of reasons. Suppose the infrastructure f=
or
> > 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 ou=
t
> 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.
>
> And for any size something similar could happen with some use case.
> But this is a great example of a situation where I would understand
> people panicking and clamoring to change the consensus rule as soon as
> possible.
> Even with much lower fees, say 1 usd/tx.
> I think it would be a great problem to have and admittedly I'm not
> worried about having it in the short term.
> And if it happened overnight we could always deploy an emergency hardfork=
.
>

Don't you think the devs should have some rough plan that they discuss
ahead of time about what to do in the situation of high fees? Even if it
happened gradually -- suppose fees crept to 20 cents, then 50 cents, then
75 over the next year -- I don't think I've ever seen a discussion of how
that should be handled, and what sort of fees people regard as high enough
to justify considering a hard fork.

I think it would prevent many people from supporting an urgent hard fork if
they knew how the core devs would handle that situation (assuming there was
some willingness to increase the block size if fees got too high).


> > 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 th=
e
> > txns from whoever was flooding the network. If you did, everything work=
ed
> > 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.
>
> [...]
> Also, yes, there is something special about this market: it is
> supposed to pay for most of the global hashrate in the not-so-far
> future.
> If we take too long to start moving away from total seigniorage
> subsidy dependence, it may be too late when we do.
>

I see that 'special' feature of this market as more strongly supporting the
need to encourage fast adoption.

Let's say block rewards are $7000 per block, and we think this gives a good
level of security (as Bitcoin grows, we'll probably want a lot more).

Suppose a 1MB block can hold 2000 txns. Then to pay for the same level of
security we have right now with only tx fees, assuming 1 MB blocks, the
average tx fee would have to be $3.50. Now suppose blocks are 100 MB in the
future. The average tx fee is then only 3.5 cents. I think the former
situation will not actually work, and the only way that Bitcoin can survive
is to eventually get into something more like the later situation. Let me
know if you want me to delve into why. I'll just note that even Lightning
doesn't work well when tx fees are that high, because channels need to be
opened and closed pretty often and if my counterparty is uncooperative, his
making me pay $3.50 starts to actually hurt.

So if we accept that, we need to end up in a situation where we eventually
have lots of people making on-blockchain txns, and paying relatively small
fees. Encouraging lots of use and experimentation of Bitcoin between now
and then seems pretty important for reaching that goal.

We're in a race with the block reward halving schedule, to see if we can
get usage high enough to pay for security (while maintaining enough
decentralization) before all of the security burden falls on transactions.
If there aren't enough transactions at that time, the burden will be too
high (or security will be too low) and people will find other solutions.

We seem to disagree about how hard it'll be to change wallet and node
software to cope with a fee market. As I've said I don't see very small
nonzero fees (for instance one tenth of a cent) as a problem though. So if
a solution that traded off usage and decentralization in a way that I
agreed with could be modified to ensure a fee market developed soon with
very low fees, I'd still support it.





>
> > 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 cou=
ld
> > 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 reac=
h
> 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 t=
o
> > 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 i=
t
> > seems unnecessary to start adding friction for users now for something
> that
> > might be an issue in 10+ years.
>
> I think you are underestimating the software costs.
> And you not only have to adapt the software that we have now, but also
> the software that hasn't been written yet and will be written assuming
> free transactions and an underdeveloped market.
> Also you are over-estimating the costs: you could hit the limit but
> then rise the block size maximum as soon as you reach, say 0.00001
> usd/tx.
> Even if minimum fees go again to zero after rising the block size
> maximum, the software improvements will remain there.
>
> > So to answer your question: about two years before we think Bitcoin wil=
l
> > 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.
>
> And when do you think "Bitcoin will need to rely heavily on txn fees
> for security"?
> How many more halvings is that?
>
> > 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.
>
> That's not what I've been arguing, I've just being saying that I would
> be completely ok with minimum fees rising above zero (say, to 1
> satoshi/tx) tomorrow.
> I don't think that's necessarily a bad thing (in fact, it has some
> advantages) and certainly not something we should fear to the point of
> rushing hardforks to avoid it.
>

--089e0122edba1a98ea051d02a62c
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 M=
on, Aug 10, 2015 at 12:28 PM, Jorge Tim=C3=B3n <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:jtimon@jtimon.cc" target=3D"_blank">jtimon@jtimon.cc</a>&gt;</s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">I would just like that there =
was an attempt to automatically<br>
estimate those risks before taking those risks.<br></blockquote><div><br></=
div><div>I agree.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
My main point about fees is that minimum mining fees rising above zero<br>
(theri current level) is not necessarily a bad thing or an urgent<br>
concern.<br></blockquote><div><br></div><div>Yes, it only gets bad when fee=
s become &quot;high.&quot;=C2=A0</div><div><br></div><div>I&#39;ll skip ove=
r the discussion of the pros/cons I listed since that mostly appeared for i=
llustrative purposes and I don&#39;t have a strong disagreement with anythi=
ng you said.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Great. I=
 don&#39;t think that minimum mining fees will rise above 1 usd<br>
cent/tx anytime soon even if we maintain the limit of 1MB.<br>
Maybe that&#39;s why I&#39;m not worried at all about &quot;hitting the lim=
it&quot;.<br></blockquote><div><br></div><div>My sense is that the people a=
rguing for a hard fork now tend to envision &quot;hitting the limit&quot; a=
s tx fees being fairly high, and those arguing against a hard fork envision=
 tx fees staying low when 1 MB blocks start to get full. Which of those occ=
urs depends on how quickly and in what manner Bitcoin gains popularity. Eve=
n if I thought there&#39;s an 95% chance that there would be no sudden jump=
 in Bitcoin tx demand, I would want to have some rough plan in place for th=
at other 5% when some previously difficult use case becomes viable and dema=
nd spikes. Do those arguing for the &quot;wait and see&quot; approach not t=
hink that a quick increase in demand is even likely enough to warrant discu=
ssing what we&#39;d do in that case? Greg Maxwell mentioned doubling the ma=
x block size if there was ever a standing backlog (<a href=3D"http://lists.=
linuxfoundation.org/pipermail/bitcoin-dev/2015-May/007880.html">http://list=
s.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/007880.html</a> -- I t=
hink fee level is a better metric than size of tx backlog), but I haven&#39=
;t seen other devs comment on it.</div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
But I&#39;m sorry, I don&#39;t have those concrete numbers because it is a<=
br>
trade-off I don&#39;t think we&#39;ve studied in enough detail.<br></blockq=
uote><div><br></div><div>The question is about what you&#39;d do in the abs=
ence of those details that you don&#39;t have. Imagine that fees spiked to =
$5/tx tomorrow. You have some model of the situation that allows you to say=
 that 1.01 MB is something you&#39;d support, and that&#39;s the model that=
 I&#39;m trying to understand. The answers I gave are not ones I&#39;m conf=
ident about. I&#39;m sure if I studied this for a week they&#39;d change. I=
 sense that devs are reluctant to answer this question because it could be =
taken out of context or held against them later. Or maybe they just don&#39=
;t like saying things that they don&#39;t have a high level of confidence a=
bout on principle. IMO this reluctance contributes to a lack of understandi=
ng of each other&#39;s positions. We all have these imperfect models in our=
 heads that we&#39;re basing our disagreements on, but we won&#39;t show ea=
ch other these models.</div><div>=C2=A0</div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><span class=3D"">
&gt; Gavin is the only other person who I&#39;ve seen who has defined at wh=
at block<br>
&gt; size he&#39;d switch to the other side (maybe not with a concrete numb=
er, but<br>
&gt; with a rough range: the block size such that a normal person with a pr=
etty<br>
&gt; good connection couldn&#39;t run a full node).<br>
<br>
</span>That would be interesting to read and I have totally missed it.<br>
Do you have a link?</blockquote><div><br></div><div>Sorry, I see how what I=
 wrote was misleading. You&#39;ve seen the email I&#39;m referring to. I wa=
s talking about when he defined the criteria he used qualitatively and sugg=
ested that&#39;s how he arrived at 20 MB:=C2=A0=C2=A0<a href=3D"http://list=
s.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/009971.html">http:/=
/lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/009971.html</a=
>. I think he talks about it in a little more detail elsewhere. I inferred =
from that that he wouldn&#39;t support 40 MB or 80 MB, but that may be wron=
g.</div><div><br></div><div>I should also have given credit to Pieter, as h=
e even more explicitly specified a level where he&#39;d turn into a hard fo=
rk advocate, via his own hard fork proposal. Neither of these statements sp=
ecifies exactly where the switch-over point is, but they&#39;re the closest=
 I&#39;ve seen.</div><div><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span cl=
ass=3D""><br>
&gt; I would say that in this case we know high tx fees could happen very s=
oon<br>
&gt; because there is a clear mechanism. Bitcoin just needs to become more<=
br>
&gt; popular quickly for any number of reasons. Suppose the infrastructure =
for<br>
&gt; remittances starts falling into place within the next two months, and<=
br>
&gt; suddenly immigrants are clamoring to use Bitcoin to send money back to=
 their<br>
&gt; home countries. This could result in $5 tx fees very soon (not that I =
think<br>
&gt; it&#39;s likely). Many of these immigrants would still use Bitcoin bec=
ause it&#39;s<br>
&gt; still better than the alternative for remittances, which would price o=
ut a<br>
&gt; lot of people currently using Bitcoin for other reasons. As far as I k=
now,<br>
&gt; there is no plausible way that subsidies could plummet in anywhere nea=
r that<br>
&gt; time frame, aside from the price of Bitcoin completely collapsing.<br>
<br>
</span>And for any size something similar could happen with some use case.<=
br>
But this is a great example of a situation where I would understand<br>
people panicking and clamoring to change the consensus rule as soon as<br>
possible.<br>
Even with much lower fees, say 1 usd/tx.<br>
I think it would be a great problem to have and admittedly I&#39;m not<br>
worried about having it in the short term.<br>
And if it happened overnight we could always deploy an emergency hardfork.<=
br></blockquote><div><br></div><div>Don&#39;t you think the devs should hav=
e some rough plan that they discuss ahead of time about what to do in the s=
ituation of high fees? Even if it happened gradually -- suppose fees crept =
to 20 cents, then 50 cents, then 75 over the next year -- I don&#39;t think=
 I&#39;ve ever seen a discussion of how that should be handled, and what so=
rt of fees people regard as high enough to justify considering a hard fork.=
=C2=A0</div><div><br></div><div>I think it would prevent many people from s=
upporting an urgent hard fork if they knew how the core devs would handle t=
hat situation (assuming there was some willingness to increase the block si=
ze if fees got too high).=C2=A0</div><div>=C2=A0</div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex"><span class=3D"">
&gt; We have seen something like this working at various points in Bitcoin&=
#39;s<br>
&gt; history. Look at the recent &quot;stress tests.&quot; To get your tx c=
onfirmed in a<br>
&gt; reasonable time frame, you had to bump your fee a little higher than t=
he<br>
&gt; txns from whoever was flooding the network. If you did, everything wor=
ked<br>
&gt; fine. If you didn&#39;t, your tx didn&#39;t confirm (until the test en=
ded, maybe?).<br>
&gt; So there&#39;s nothing complicated here. It doesn&#39;t require a deca=
de long<br>
&gt; preparation to prove to ourselves that a fee market will work.<br>
<br></span>[...]<br>
Also, yes, there is something special about this market: it is<br>
supposed to pay for most of the global hashrate in the not-so-far<br>
future.<br>
If we take too long to start moving away from total seigniorage<br>
subsidy dependence, it may be too late when we do.<br></blockquote><div><br=
></div><div>I see that &#39;special&#39; feature of this market as more str=
ongly supporting the need to encourage fast adoption.=C2=A0</div><div><br><=
/div><div>Let&#39;s say block rewards are $7000 per block, and we think thi=
s gives a good level of security (as Bitcoin grows, we&#39;ll probably want=
 a lot more).</div><div><br></div><div>Suppose a 1MB block can hold 2000 tx=
ns. Then to pay for the same level of security we have right now with only =
tx fees, assuming 1 MB blocks, the average tx fee would have to be $3.50. N=
ow suppose blocks are 100 MB in the future. The average tx fee is then only=
 3.5 cents. I think the former situation will not actually work, and the on=
ly way that Bitcoin can survive is to eventually get into something more li=
ke the later situation. Let me know if you want me to delve into why. I&#39=
;ll just note that even Lightning doesn&#39;t work well when tx fees are th=
at high, because channels need to be opened and closed pretty often and if =
my counterparty is uncooperative, his making me pay $3.50 starts to actuall=
y hurt.=C2=A0</div><div><br></div><div>So if we accept that, we need to end=
 up in a situation where we eventually have lots of people making on-blockc=
hain txns, and paying relatively small fees. Encouraging lots of use and ex=
perimentation of Bitcoin between now and then seems pretty important for re=
aching that goal.</div><div><br></div><div>We&#39;re in a race with the blo=
ck reward halving schedule, to see if we can get usage high enough to pay f=
or security (while maintaining enough decentralization) before all of the s=
ecurity burden falls on transactions. If there aren&#39;t enough transactio=
ns at that time, the burden will be too high (or security will be too low) =
and people will find other solutions.</div><div><br></div><div>We seem to d=
isagree about how hard it&#39;ll be to change wallet and node software to c=
ope with a fee market. As I&#39;ve said I don&#39;t see very small nonzero =
fees (for instance one tenth of a cent) as a problem though. So if a soluti=
on that traded off usage and decentralization in a way that I agreed with c=
ould be modified to ensure a fee market developed soon with very low fees, =
I&#39;d still support it.</div><div><br></div><div><br></div><div><br></div=
><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=3D""><br>
&gt; Unless in the future mining is funded mostly by charity (I think there=
&#39;s<br>
&gt; only a 25% chance of that happening), we will need a fee market eventu=
ally.<br>
&gt; I&#39;d be fine if one developed now. I think 10 cents per txn right n=
ow<br>
&gt; wouldn&#39;t be too bad, aside from the following reason. What concern=
s me about<br>
&gt; insisting on a fee market right now is that usage is so small and the =
block<br>
&gt; size is so limited that if demand increases just a little bit, fees co=
uld<br>
&gt; skyrocket. It&#39;s not the 10 cent fees that would worry me, but what=
 they say<br>
&gt; about the potential for a huge spike. Fees could become $10 per tx or =
higher<br>
&gt; very quickly. Yes, that would show that big organizations find Bitcoin=
<br>
&gt; useful which is nice, but it&#39;d also put decentralized money out of=
 reach of<br>
&gt; many other people. While Bitcoin still has a lot of growth ahead of it=
, it&#39;s<br>
&gt; better to not set up roadblocks (for reasons other than preserving<br>
&gt; decentralization) in front of that growth which will make things very<=
br>
&gt; painful if that growth happens more suddenly than we expect.<br>
&gt;<br>
&gt; I think the best argument for having a fee market right now is that if=
 we<br>
&gt; move to such a market suddenly in the future, wallets won&#39;t have t=
ime to<br>
&gt; make the user experience good, and full nodes might not be written in =
such a<br>
&gt; way that they gracefully handle a bunch of txns that might never confi=
rm. I<br>
&gt; don&#39;t think the required software changes are that complex though,=
 so it<br>
&gt; seems unnecessary to start adding friction for users now for something=
 that<br>
&gt; might be an issue in 10+ years.<br>
<br>
</span>I think you are underestimating the software costs.<br>
And you not only have to adapt the software that we have now, but also<br>
the software that hasn&#39;t been written yet and will be written assuming<=
br>
free transactions and an underdeveloped market.<br>
Also you are over-estimating the costs: you could hit the limit but<br>
then rise the block size maximum as soon as you reach, say 0.00001<br>
usd/tx.<br>
Even if minimum fees go again to zero after rising the block size<br>
maximum, the software improvements will remain there.<br>
<span class=3D""><br>
&gt; So to answer your question: about two years before we think Bitcoin wi=
ll<br>
&gt; need to rely heavily on txn fees for security, I&#39;d be in favor of =
adjusting<br>
&gt; block size so that it resulted in enough total fees / security.<br>
<br>
</span>And when do you think &quot;Bitcoin will need to rely heavily on txn=
 fees<br>
for security&quot;?<br>
How many more halvings is that?<br>
<span class=3D""><br>
&gt; You&#39;ve been arguing that 0 fee transactions will have to disappear=
 someday,<br>
&gt; but this isn&#39;t necessarily true. As long as enough people care abo=
ut having<br>
&gt; their txns confirm relatively quickly, there&#39;s no reason to make s=
ure that<br>
&gt; people who pay 0 fees never have their txns confirmed.<br>
<br>
</span>That&#39;s not what I&#39;ve been arguing, I&#39;ve just being sayin=
g that I would<br>
be completely ok with minimum fees rising above zero (say, to 1<br>
satoshi/tx) tomorrow.<br>
I don&#39;t think that&#39;s necessarily a bad thing (in fact, it has some<=
br>
advantages) and certainly not something we should fear to the point of<br>
rushing hardforks to avoid it.<br>
</blockquote></div><br></div></div>

--089e0122edba1a98ea051d02a62c--