path: root/b3/23c8f15d32558b6eb3edde61bcf63bfd7f6ac3

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 30A84273
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  6 Aug 2015 01:26:12 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com
	[209.85.212.179])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0F4271B4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  6 Aug 2015 01:26:10 +0000 (UTC)
Received: by wicne3 with SMTP id ne3so3699104wic.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 05 Aug 2015 18:26:09 -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=Uor9j4Vz6YakoH1LM07oVkmyjzoEui3b2MrS5jUPGfw=;
	b=Cg/g1Rn+TuWovZCJcAx8obgMXxLxoU5mlY/+1lOA/ExoJYO++DJnIHwgaqwCgB+2sx
	4KTb7jmf77POWju5BhLwkHaRlRZWsFn0k3hBUSxuj2gDtlMYaeWKjJf51l0Xzd8pO9Vy
	Pf0ie3YNTcKWZgkpKRgIhvkjwOkvhOBx+uYTxo7ij28YaKzerm/Vt20v3JNlJ7m71jTb
	t0QNyoMI1x3exXIpp6RN82lvf/ET57uh4JaPoGLzOFNUSN67wcw4otAQz4M89JJkSK1x
	uCpaJifsgudpvjM3cfNCdGB1Q+rzecHxqs839jrNuAibugFlUIzbvA83g8ORnHMAXnq1
	pUwQ==
X-Gm-Message-State: ALoCoQmBd6HQcY0AuzqFYOWeCqneZOq/eEyyvGfOWYy24KpeCJgwLSxtg1CZMBjFDQn93AaYE86J
MIME-Version: 1.0
X-Received: by 10.180.109.106 with SMTP id hr10mr1261800wib.58.1438824369539; 
	Wed, 05 Aug 2015 18:26:09 -0700 (PDT)
Received: by 10.194.31.230 with HTTP; Wed, 5 Aug 2015 18:26:09 -0700 (PDT)
In-Reply-To: <CA+BnGuFNOjzLaiPPnUSi-rkU94UMgmP30Si8N3oBSYG0q8j-_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>
Date: Thu, 6 Aug 2015 03:26:09 +0200
Message-ID: <CABm2gDoNbhc1=kgc0F+wSm33hTmRmmptk-XcaZxsm=6iJkWu=w@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: Thu, 06 Aug 2015 01:26:12 -0000

On Wed, Aug 5, 2015 at 9:29 AM, Elliot Olds <elliot.olds@gmail.com> wrote:
> On Tue, Aug 4, 2015 at 4:59 AM, Jorge Tim=C3=B3n
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> Also I don't think "hitting the limit" must be necessarily harmful and
>> if it is, I don't understand why hitting it at 1MB will be more
>> harmful than hitting it at 2MB, 8MB or 8GB.
>
>
> I don't think merely hitting the limit is bad. The level of tx fees in
> equilibrium give some clue as to the level of harm being done. If fees ar=
e
> at $5/tx at 1MB, it's about as bad as if fees are at $5/tx at 4MB.

This is a much more reasonable position. I wish this had been starting
point of this discussion instead of "the block size limit must be
increased as soon as possible or bitcoin will fail".
If the only fear about not increasing the block size fast enough is
that fees may rise, pieter wouldn't had to repeatedly explain that for
any reasonable block size some use case may fill the blocks rapidly.

>> There is NO criterion based on mining centralization to decide between
>> 2 sizes in favor of the small one.
>> It seems like the rationale it's always "the bigger the better" and
>> the only limitation is what a few people concerned with mining
>> centralization (while they still have time to discuss this) are
>> willing to accept. If that's the case, then there won't be effectively
>> any limit in the long term and Bitcoin will probably fail in its
>> decentralization goals.
>> I think its the proponents of a blocksize change who should propose
>> such a criterion and now they have the tools to simulate different
>> block sizes.
>
>
> In the absence of harder data, it might be interesting to use these
> simulations to graph centralization pressure as a function of bandwidth c=
ost
> over time (or other historical variables that affect centralization). For
> instance, look at how high centralization pressure was in 2009 according =
to
> the simulations, given how cheap/available bandwidth was then, compared t=
o
> 2010, 2011, etc. Then we could figure out: given today's bandwidth
> situation, what size blocks right now would give us the same centralizati=
on
> pressure that we had in 2011, 2012, 2013, etc?
>
> Of course this doesn't mean we should blindly assume that the level of
> centralization pressure in 2012 was acceptable, and therefore any block s=
ize
> increase that results in the same amount of pressure now should be
> acceptable. But it might lead to a more productive discussion.

This sounds good overall but I'm afraid you are oversimplifying some things=
.
Centralization pressure not only comes from global average bandwidth
costs and block propagation times is not the only concern.
Here's an extreme example: [1]
But anyway, yes, I agree, ANY metric would be better than nothing (the
current situation).

>> I want us to simulate many blocksizes before rushing into a decision
>> (specially because I disagree that taking a decision there is urgent
>> in the first place).
>
>
> IMO it is not urgent if the core devs are committed to reacting to a huge
> spike in tx fees with a modest block size increase in a relatively short
> time frame, if they judge the centralization risks of that increase to be
> small. Greg Maxwell posted on reddit a while back something to the effect=
 of
> "the big block advocates are overstating the urgency of the block size
> increase, because if there was actually a situation that required us to
> increase block size, we could make the increase when it was actually
> needed." I found that somewhat persuasive, but I am concerned that I have=
n't
> seen any discussion of what the "let's wait for now" camp would consider =
a
> valid reason to increase block size in the short term, and how they'd mak=
e
> the tradeoff with tx fees or whatever else was necessitating the increase=
.

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

> Jorge, if a fee equilibrium developed at 1MB of $5/tx, and you somehow kn=
ew
> with certainty that increasing to 4MB would result in a 20 cent/tx
> equilibrium that would last for a year (otherwise fees would stay around =
$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.

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? 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".
To the question

- At which minimum mining fee rate will you urge others to change the
consensus rules to increase the block size?

I'm very sorry, but my answer is:

- I honestly don't know, that may never happen.

What I can tell you is this: I will never be worried about "too high
fees" while the fees remain at 0 (null, zero, nothing, cero, nada,
zilch).
That's right, no matter what wallet's defaults chose for their users,
no matter what the minimum relay fee policy does to the "fee market"
and how much urgent transactions pay in fees; the fact remains that in
practice non-urgent transactions usually (when the raw transaction's
structure it's appropriate) don't have to pay fees.

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.

> For those familiar with the distinction between near/far mode thinking
> popularized by Robin Hanson: focusing on concrete examples like this
> encourages problem solving and consensus, and focusing on abstract
> principles (like decentralization vs. usability in general) leads to peop=
le
> toward using argument to signal their alliances and reduce the status of
> their opponents.

I really appreciate your efforts to mediate in this dispute and I
honestly hope that my previous answer is useful as it is.

> I think it'd be very helpful if more 1MB advocates
> described what exactly would make them say "OK, in this situation a block
> size increase is needed, we should do one quickly!", and also if
> Gavin/Mike/Jeff described what hypothetical scenarios and/or test results
> would make them want to stick with 1MB blocks for now.

Just replace 1MB with ANY size.
But, yes, please, when will you consider a size to be too dangerous
for centralization?
Why 20 GB would have been safe but 21 GB wouldn't have been (or the
respective maximums and respective +1)?

Note that "Never, 20GB was just a number closer to infinity than 1MB
and I hoped that could had been voluntarily accepted by users. What I
really want is to completely remove this consensus rule forever." is a
perfectly valid answer. It just means that I will agree with people
that think this way as explained in [1] (yes, not even after
superluminal communication).

As an less relevant note, I feel extremely uncomfortable about being
included in the "1MB advocates" group. As I've tried to explain
several times, 1 is to me an arbitrary number like any other (at most,
the canonical arbitrary number), and so it is 1000000
(MAX_BLOCK_SIZE). I rarely like being grouped or labelled, but maybe
something more accurate like "not-recklessly-change-consensus-rules
advocates" would help.
There's nothing special about 1MB apart from being the current rule,
so I don't think the number is that much relevant to the discussion.
Grouping anyone that has raised any concern about rising the consensus
block size limit as "the 1MBers" is about as fair as grouping anyone
that has ever proposed a rise in the maximum size as "the 20GBers"
(specially when there's people that belong to both groups
simultaneously, like Pieter Wuille who started this thread, and whose
proposal we're supposed to be discussing).

[1] http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/0099=
47.html