path: root/0f/d3399815b2ca9bf071c819b3f5e5ad177f9e2f

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 041FB305
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  6 Aug 2015 21:51:03 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com
	[209.85.212.181])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C75DB118
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  6 Aug 2015 21:51:01 +0000 (UTC)
Received: by wibxm9 with SMTP id xm9so41796127wib.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 06 Aug 2015 14:51:00 -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=UppBvbJbL+czVXo1Fyf/TVSGghCr5IfE9qtLPlkT5ak=;
	b=IXVCa6yZfAyTX0Q91GxpX8Olk3rZUW8SVaU1s48zK3WPG9KwvU+KOFgOuU6AQODFoG
	FGNe9t0vSN6Q0NGRasqx1G1vRhd6Y8YlaklmF42vgW6X6pmyxzzLzSJsb1h03vIeyhhJ
	pwSLyeiRzxXkcvoBZVSDRB2mSxJ+0jbJsThTg273q8QA10Y0JUM32gzsGjR5tTC9RY/I
	cuWLw0Pu0t9Lsm743J3wQCULv3YlJforDa5bPsxdrnBBMzegQOb57LeZdAwJRq964hFY
	aOeuafSUCD9bAHcqqNTorAVMR52enVbYdPaPZ2/FevIYm/DL6311GJzByX2XN+qZbWF0
	46OQ==
X-Gm-Message-State: ALoCoQlgTXJjjKbFlfJbYNf2ekCg8zVJu+zoH8m8WoExWP5dKrg/GTne10R31EB1qkWdTyo1cwn5
MIME-Version: 1.0
X-Received: by 10.194.122.97 with SMTP id lr1mr7655209wjb.26.1438897860392;
	Thu, 06 Aug 2015 14:51:00 -0700 (PDT)
Received: by 10.194.31.230 with HTTP; Thu, 6 Aug 2015 14:51:00 -0700 (PDT)
In-Reply-To: <CABsx9T3KH_pbUc+Yu4wRmWHcF1e6fEtPzLzZddwDrQBMzoZPVg@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>
	<CABm2gDok2WuYhGtqqvaJPez4i8Y8E4MXcCrg81ewK2j=grd45A@mail.gmail.com>
	<CABsx9T3KH_pbUc+Yu4wRmWHcF1e6fEtPzLzZddwDrQBMzoZPVg@mail.gmail.com>
Date: Thu, 6 Aug 2015 23:51:00 +0200
Message-ID: <CABm2gDpnikt4o9EE1Gm2g009gJa1sVtuwDM-iQgwue2ijiNLvQ@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
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 21:51:03 -0000

Really, thanks again for replying and not getting mad when I get your
thoughts wrong.
I believe that I've learned more about your position on the subject
today than in months of discussion and blogs (that's not a critique to
your blog post, it's just that they didn't answer to some questions
that I personally needed responded).

On Thu, Aug 6, 2015 at 9:42 PM, Gavin Andresen <gavinandresen@gmail.com> wr=
ote:
> On Thu, Aug 6, 2015 at 1:15 PM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote=
:
>>
>> 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?
>
>
> Two answers:
>
> 1. If you are willing to wait an infinite amount of time, I think the
> minimum fee will always be zero or very close to zero, so I think it's a
> silly question.

I'm very happy to have made the stupid question then. It has revealed
another big difference in the fundamental assumptions we're using.

My assumption is that for any reasonable size, free transactions will
eventually disappear (assuming Bitcoin doesn't "fail" for some other
reason).
Maybe I'm being too optimistic about the demand side of the market in
the long term.

In contrast, your assumption seems to be (and please correct me on
anything I get wrong) that...

"The limit will always be big enough so that free transactions are
mined forever. Therefore fees just allow users to prioritize their
urgent transactions and relay policies to protect their nodes against
DoS attacks.
Well, obviously, they also serve to pay for mining in a low-subsidy
future, but even with the presence of free transactions, fees will be
enough to cover mining costs, or a new mechanisms will be developed to
make a low-total-reward blockchain safe or expensive proof of work
will be replaced or complemented with something else that's cheaper.
The main point is that fees are not a mechanism to decide what gets
priced out of the blockchain, because advancements in technology will
always give as enough room for free transactions."
- jtimon putting words in Gavin's mouth, with the only intention to
understand him better.

I'm using "free transactions" even though you said "zero or very close to z=
ero".
To you, "zero or very close to zero" may be the same thing, but to me
zero and very close to zero are like...different galaxies.
To me, entering the "very close to zero galaxy" is a huge step in the
development of the fee market.
I've been always assuming that moving from zero to 1 satoshi was
precisely what "big block advocates" wanted to avoid.
What they meant by "Bitcoin is going to become a high-value only
network" and similar things.
Knowing that for "big block advocates" zero and "very close to zero"
are equally acceptable changes things.

> 2. The "market minimum fee" should be determined by the market. It should
> not be up to us to decide "when is a good time."

I completely agree, but the block size limit is a consensus rule that
doesn't adapt to the market. The market will adapt to whatever limit
is chosen by the consensus rules.

>> 2) Do you have any criterion (automatic or not) that can result in you
>> saying "no, this is too much" for any proposed size?
>
>
> Sure, if keeping up with transaction volume requires a cluster of compute=
rs
> or more than "pretty good" broadband bandwidth I think that's too far.
> That's where original 20MB limit comes from, otherwise I'd have proposed =
a
> much higher limit.
>
>> Would you agree that blocksize increase proposals should have such a
>> criterion/test?
>
>
> Although I've been very clear with my criterion, no, I don't think all
> blocksize increase proposals should have to justify "why this size" or "w=
hy
> this rate of increase."

I would really like a more formal criterion, ideally automatic (like
any other test, the parameters can be modified as technology
advances).
But fair enough, even though your criterion is too vague or not
future-proof enough, I guess it is still a criterion.
It seems that this is a matter of disagreements and ideal ways of
doing things and not really a disagreement on fundamental assumptions.
So it seems this question wasn't so interesting after all.

> Part of my frustration with this whole debate is
> we're talking about a sanity-check upper-limit; as long as it doesn't ope=
n
> up some terrible new DoS possibility I don't think it really matters much
> what the exact number is.

That's what you think you are discussing, but I (and probably some
other people) think we are discussing something entirely different.
Because we have a fundamentally different assumption on what the block
size limit is about.
I really hope that identifying these "fundamental assumption
discrepancies" (FAD from now own) will help us avoid circular
discussions so that everything is less frustrating and more productive
for everyone.

>> 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?
>
>
> It prevents trivial denial-of-service attacks (e.g. I promise to send you=
 a
> 1 Terabyte block, then fill up your memory or disk...).

This could be prevented in some other ways. If this is the only
concern, it doesn't need to be a consensus rule.

> And please read what I wrote: I said that the block limit has LITTLE effe=
ct
> on MINING centralization.  Not "no effect on any type of centralization."
>
> If the limit was removed entirely, it is certainly possible we'd end up w=
ith
> very few organizations (and perhaps zero individuals) running full nodes.

Sorry, another try:

You think the maximum block size rule serves to limit centralization
by limiting how hard it is to run a full node.
I agree with that, but I would add something more and you wouldn't:

The maximum block size consensus rule limits how hard it is to be a
competitive miner.

In other words, you think the last statement is false or incorrect.

Meta: I think we should try to collect and list more of this "FADs"
(we have at least 2 of them already). If you think it can be useful,
I'm more than happy to repeat this process in the opposite direction:
you make the questions and I give the answers, you write what you
think I think and I correct you in iterations. Probably we should
finish with you correcting what I think you think first. I am really
excited about understanding your point of view better.

Stupid humor (hopefully not out of context and not offensive): I'm
happy to discover that what I thought it was FUD was just FAD.
More seriously, I'm really happy for your interest in understanding
and being understood.
Let's worry about where do we think differently first and about who is
right on each point later.
In the end, only the conclusions on each point will matter and not who
claimed the final conclusions (in the points where we find them) first
(if we get to final common conclusions on that point at all).