1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
|
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 2618489D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 6 Aug 2015 17:15:33 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com
[209.85.212.177])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2FA411C1
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 6 Aug 2015 17:15:04 +0000 (UTC)
Received: by wibhh20 with SMTP id hh20so33249565wib.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 06 Aug 2015 10:15:02 -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=hOgNzwcP1T3/8ZIg7SFkrhf5NAYEykoBtRV+AAnVYjQ=;
b=cwQOH2mR6qyRToQaOxOaEKM+ayWuVysWq8AVbFB5BbVu96Z4Zfx4y80rwmDWqUJc1k
D8XYEVP2dhDyUeVFwOkmx30u5RRQEIZxxNIAKWn8RHfgAvJtRSSGXHzvFJkmzjLkb7vr
H3fXMUcAcjJQarGJsDwZ3hmxuEhsimAfZcIlQXsgXvqDG2wBgmv5eVCh5e4mrPRHsMEn
UHNQmDLFntNId6dchEnVVEsZ26OCyuBpnuTqGIxDBOvgys/siD5aYP9B2KcD05S80T0U
rU5ub/BO0mbIDefR8FoOWhVV2H799rOfJTlPpt9Toy6h5iM3bg7rrs4MfvyBxgaiPTal
ZN9Q==
X-Gm-Message-State: ALoCoQluBi7nn0NFzVb1YNRP2c6q69NlgbMHoTYUU5l+7tOX7Brly3k8egUNOOcoE2I1qPGAzb3B
MIME-Version: 1.0
X-Received: by 10.180.230.199 with SMTP id ta7mr3453929wic.1.1438881302703;
Thu, 06 Aug 2015 10:15:02 -0700 (PDT)
Received: by 10.194.31.230 with HTTP; Thu, 6 Aug 2015 10:15:02 -0700 (PDT)
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
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
autolearn=unavailable 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 17:15:33 -0000
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.
|
