path: root/93/15da16596b0a12e7466cf0b4f35c513bf3330f

Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id BAF48267
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 10 Aug 2015 19:28:51 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com
	[209.85.212.169])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3C2F91A4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 10 Aug 2015 19:28:50 +0000 (UTC)
Received: by wicja10 with SMTP id ja10so39222189wic.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 10 Aug 2015 12:28:48 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=ciL9I8HnwqwgeHVrJlgmeo03cEMNcdIfbnhPLBnmyKs=;
	b=GBA1JaAZ4oFCNVoJK3kZlctc+yexu8p8M4Lpjx+Y+wHQW13EOqJAj68R6yaP+21wv2
	tM30uMDxBl8PopGJ+QF21Etoezb46rHiRGpWrrBXNmsurlnZPIuIGh11ToL78Fiau5ud
	aHhO3M4+rHtuoo5IbhNm50dZoq+1K5h7KXyYW9HIbO+FaKzpbSb9/dNvZyLqkNZlrZEX
	egSvJcI5pOgupOe913erwhLnmoJk3Ps1NCm6iFkcDKAEwm9pJjG3pa5R4xyG1sbEkpUh
	SD2epJlBGYVeeC2n+Sz3keHRzZamnWcQSJUNWAd34KsvSnF6mVvRYlU+IG3R5XH34mdw
	WXig==
X-Gm-Message-State: ALoCoQmqlGU8ip9zZu+RS72zj3F8v2zttjusBLvnYgDIJmPM0f2TTVzbnkXd6jyPdo2SRjOHfWb+
MIME-Version: 1.0
X-Received: by 10.194.120.198 with SMTP id le6mr47076575wjb.133.1439234928809; 
	Mon, 10 Aug 2015 12:28:48 -0700 (PDT)
Received: by 10.194.31.230 with HTTP; Mon, 10 Aug 2015 12:28:48 -0700 (PDT)
In-Reply-To: <CA+BnGuE1bcFaL70+dvsRgtZib2t+Ogku3rfPSwV-2qjRAVdEcA@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>
Date: Mon, 10 Aug 2015 21:28:48 +0200
Message-ID: <CABm2gDpGVpb+ZYF-Cg_dFM5aoCM5mADvM5dUqKBmGX_1P6=76A@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Elliot Olds <elliot.olds@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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] 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: Mon, 10 Aug 2015 19:28:51 -0000

On Fri, Aug 7, 2015 at 1:09 AM, Elliot Olds <elliot.olds@gmail.com> wrote:
> On Wed, Aug 5, 2015 at 6:26 PM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote=
:
> I agree with you that decentralization is the most important feature of
> Bitcoin, but I also think we need to think probabilistically and concrete=
ly
> 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.
> [...]
> Similarly we shouldn't accept a 100% probability of Bitcoin being control=
led
> by a single entity for any guarantee of cheap tx fees no matter how low t=
hey
> 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 someh=
ow
> allowed us to dramatically increase usability. (Imagine something like th=
e
> Lightning Network but even better was developed, but it could only work w=
ith
> 1.01 MB blocks).

Agreed. I would just like that there was an attempt to automatically
estimate those risks before taking those risks.
Some function we're trying to optimize with simulations (based on
#6382 ) to find an ideal (according to that imperfect metric) maximum
consensus block size.
Maybe the function/simulations just take some minimum hardware
specifications and returns an block size, I don't know.

> 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 i=
f
> there are any risks that you think don't matter at 4 MB but that you woul=
d
> be worried about at higher block size levels. I also don't know if we hav=
e
> 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.

The most important thing to understand in this discussion is that it
is about a trade-off between lower fees (more maximum tx volume) and
mining (and general) centralization.
I don't know what the costs and gains curves are here (for 4MB, 1 MB
or any other number, and I don't think anybody does).
But if we can't even agree on what the advantages and disadvantages of
increasing the consensus block size maximum, it is very hard that we
can agree on a universally acceptable point or range in this trade-off
rect.

> For the record, I think these are the main harms of $5 tx fees, along wit=
h
> 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 ge=
t
> immediate benefit from it now.
> (b) Prevent developers from experimenting with new Bitcoin use-cases, whi=
ch
> might eventually lead to helpful services.
> (c) Prevent regular people from using Bitcoin and experimenting with it a=
nd
> 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.

This is all probably right, but IMO we're very far away from $5/tx.
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.
On the other hand, we have much more data about current mining
centralization, which should be very relevant information when
discussing a block size increase.

> Changing the block size to 4 MB would:
> (1) Probably reduce the number of full nodes by around 5%. Most of the dr=
op
> in full nodes over the past few years is probably due to Bitcoin Core bei=
ng
> used by fewer regular users for convenience reasons, but the extra HD spa=
ce
> required and extra bandwidth would probably make some existing people
> running full nodes stop.

As Pieter has explained repeatedly, a big block count is not a goal in
itself, just a metric.
And if you ask me, I don't think it's all that interesting as a
metric. For all I know there could be a lot more full nodes being run
that for whatever reason are not seen by people collecting this data.
The block size maximum consensus rule limits mining centralization,
not just full node centralization. Gavin, for example, disagrees with
this.
Fortunately I believe at least 2 mathematical proofs can be produced
to demonstrate Gavin and those who think like him are wrong.

> (2) Not hinder low bandwidth miners significantly, because of the relay
> network.

I believe that even with the relay network, and even assuming all
miners are connected using something like IBLT, a mathematical proof
can be constructed to demonstrate that bigger block sizes can prevent
the worse connected miners from being profitable.
It is important to note that the worse connected miners aren't
necessarily those with less bandwidth: maybe you have the best
bandwidth but you are poorly connected to the majority of the hashrate
(for example, because the majority of the hashrate is within the same
country but that country is not very well connected to the rest of the
world).

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

We're certainly far away from this being a concern in practice.
But I'm working on a mathematical proof that at some scale CPU
requirements could become a discriminating factor making the smallest
mining operations unprofitable.

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

I don't think there's such a thing as a "dangerous full node count level".
It's just data that can be useful to build centralization metrics.
Probably hashrate distribution by pool is much more interesting (and
if you ask me that looks really bad right now without increasing the
block size consensus maximum).

> 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 though=
t
> process and about the hypothetical situation results in much better
> discussions.

I agree.

> 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). I=
f
> 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 ov=
er
> to being a 1 MB advocate. Getting that same info from you tells me exactl=
y
> 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 increa=
se
> 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 t=
he
> block size to 1.01 MB, I would be really surprised.

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".
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.
Well, I can also say I wouldn't be worried at all about moving to,
say, 1.01 MB (because the difference in centralization pressure should
be minimal) and I would just take it as a "let's proof hardforks are
possible" change similar to the one proposed in bip99.

> Gavin is the only other person who I've seen who has defined at what bloc=
k
> 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 prett=
y
> 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?

> 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 th=
eir
> home countries. This could result in $5 tx fees very soon (not that I thi=
nk
> 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 t=
hat
> 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.

> But if
> that happens in the near term (specifically, with very low tx volume) a f=
ee
> market won't help.

I think it's helping by determining who is to be served first, and
that is those who benefit more from Bitcoin (and are therefore willing
to pay higher costs for using it), in this case, people doing
international remittances.

> 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 th=
e
> cases where people need even cheaper txns.

Agreed.

>> 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 abo=
ut
> a fee market now:
>
> There is nothing particularly special about a fee market in Bitcoin. We k=
now
> how markets work, and we have no reason to suspect a fee market in Bitcoi=
n
> will have any new properties of markets that we can't foresee. When deman=
d
> becomes higher, there will be some equilibrium level of fee that people h=
ave
> 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.

This is what I mean by "market minimum fee".

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

I think the code that miners use to select which transactions to
include first needs a lot of work.
As said miners are subsidizing free transactions, increasing their own
costs for nothing in exchange.
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.

> 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 eventuall=
y.
> 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 ab=
out
> 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 could
> skyrocket. It's not the 10 cent fees that would worry me, but what they s=
ay
> about the potential for a huge spike. Fees could become $10 per tx or hig=
her
> 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, i=
t'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 suc=
h 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 th=
at
> 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 will
> need to rely heavily on txn fees for security, I'd be in favor of adjusti=
ng
> 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 someda=
y,
> but this isn't necessarily true. As long as enough people care about havi=
ng
> their txns confirm relatively quickly, there's no reason to make sure tha=
t
> 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.