MIME-Version: 1.0
In-Reply-To: <CABsx9T3ARTAV58LYSr40VJsttO5kAtLxMDMZwkKH+ztXYw13mg@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>
	<CABsx9T22KUcbRb4ZfRDikbxK05pqWY1=uvYo10toWA-JwGa-PQ@mail.gmail.com>
	<CABm2gDo6bpWst-8=pr4+et+jrwNX5bt5CwSTsm5OSj1pncayjA@mail.gmail.com>
	<CABsx9T3ARTAV58LYSr40VJsttO5kAtLxMDMZwkKH+ztXYw13mg@mail.gmail.com>
Date: Thu, 6 Aug 2015 19:15:02 +0200
Message-ID: <CABm2gDok2WuYhGtqqvaJPez4i8Y8E4MXcCrg81ewK2j=grd45A@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Block size following technological growth
Precedence: list

First of all, thank you very much for answering the questions, and
apologies for not having formulated them properly (fortunately that's
not an irreparable mistake).

On Thu, Aug 6, 2015 at 6:03 PM, Gavin Andresen <gavinandresen@gmail.com> wr=
ote:
> On Thu, Aug 6, 2015 at 11:25 AM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrot=
e:
>>
>> 1) If "not now" when will it be a good time to let fees rise above zero?
>
>
> Fees are already above zero. See
> http://gavinandresen.ninja/the-myth-of-not-full-blocks

When we talk about "fees" we're talking about different things. I
should have been more specific.
Average fees are greatly influenced by wallet and policy defaults, and
they also include extra fees that are included for fast confirmation.
I'm not talking about fast confirmation transactions, but about
non-urgent transactions.

What is the market minimum fee for miners to mine a transaction?

That's currently zero.
If you don't want to directly look at what blocks contain, we can also
use a fee estimator and define a "non-urgent period", say 1 week worth
of blocks (1008 blocks).
The chart in your link doesn't include a 1008 blocks line, but the 15
blocks (about 2.5 hours) line seems to already show zero fees:

http://img.svbtle.com/p4x3s7fn52sz9a.png

So I reformulate the question:

1) If "not now", when will it be a good time to let the "market
minimum fee for miners to mine a transaction" rise above zero?

>> 2) When will you consider a size to be too dangerous for centralization?
>> In other words, why 20 GB would have been safe but 21 GB wouldn't have
>> been (or the respective maximums and respective +1 for each block
>> increase proposal)?
>
>
> http://gavinandresen.ninja/does-more-transactions-necessarily-mean-more-c=
entralized

This just shows where the 20 GB come from, not why you would reject 21 GB.
Let me rephrase.

2) Do you have any criterion (automatic or not) that can result in you
saying "no, this is too much" for any proposed size?
Since you don't think the consensus block size maximum limits mining
centralization (as you later say), it must be based on something else.
In any case, if you lack a criterion that's fine as well: it's never
too late to have one.
Would you agree that blocksize increase proposals should have such a
criterion/test?

>> 3) Does this mean that you would be in favor of completely removing
>> the consensus rule that limits mining centralization by imposing an
>> artificial (like any other consensus rule) block size maximum?
>
>
> I don't believe that the maximum block size has much at all to do with
> mining centralization, so I don't accept the premise of the question.

Ok, this is an enormous step forward in the discussion, thank you.
In my opinion all discussions will be sterile while we can't even
agree on what are the positive effects of the consensus rule that
supposedly needs to be changed.

It's not that you don't care about centralization, it's that you don't
believe that a consensus block size maximum limits centralization at
all.
This means that if I can convince you that the consensus block size
maximum does in fact limit centralization in any way, you may change
your views about the whole blocksize consensus rule change, you may
even take back or change your own proposal.
But let's leave that aside that for now.

Regardless of the history of the consensus rule (which I couldn't care
less about), I believe the only function that the maximum block size
rule currently serves is limiting centralization.
Since you deny that function, do you think the (artificial) consensus
rule is currently serving any other purpose that I'm missing?

If the answer is something along the lines of "not really, it's just
technical debt", then I think you should be honest and consequent, and
directly advocate for the complete removal of the consensus rule.

I really think conversations can't really advance until we clarify the
different positions about the discussed consensus rule current
purpose.