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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jtimon@jtimon.cc>) id 1YqQAs-00019g-I8
for bitcoin-development@lists.sourceforge.net;
Thu, 07 May 2015 18:05:30 +0000
Received: from mail-wi0-f178.google.com ([209.85.212.178])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YqQAq-00020n-Qk
for bitcoin-development@lists.sourceforge.net;
Thu, 07 May 2015 18:05:30 +0000
Received: by wizk4 with SMTP id k4so1111228wiz.1
for <bitcoin-development@lists.sourceforge.net>;
Thu, 07 May 2015 11:05:22 -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=0lq9unNXLTs5grC/xsW6CqESctqwDJduvBu3+4gMBrg=;
b=SCrIUre50r8b9C2FpCqif19CZcdYh0VNtdzpyNA8zrJann4jvggN8u64XhHqDc6rcH
D1AiY9toQ0EGhYN5P8riO4HiaMNlVKQUcZ2YA+ewy00runHC7yRRurrUO5qWzQ9gUvCH
jSRDYPy2UvcKLY81N7dQEq/hfPQa8Zw5Da+cCyj9TUai8YX/JpZXaM6dXedWnCS6CRlX
SFxIr4EfcE9BNEVd9h6CPRGPRDsMQAHB1X0DKovHVkm3gyWPoe8xDc99uG3LcHeMsiRa
9bTozREeer2X5ATrRSoNfx/JrL2rlnJpZSXTOFOSWiVkqjfvOfNa/LfZ9OvEWC7URecG
DPxw==
X-Gm-Message-State: ALoCoQk1oD31/47lFUxIlUuU7ju/e8qwKoD7Qe1v1kWsWqho32grUretSbJl416kzfvfKvI+H9oX
MIME-Version: 1.0
X-Received: by 10.180.188.193 with SMTP id gc1mr8865367wic.7.1431021922716;
Thu, 07 May 2015 11:05:22 -0700 (PDT)
Received: by 10.194.124.2 with HTTP; Thu, 7 May 2015 11:05:22 -0700 (PDT)
In-Reply-To: <CABsx9T1nwastEoN12B2Y-TA2V1fYtDcm9-nkiOQNVhXmbCjcGQ@mail.gmail.com>
References: <554A91BE.6060105@bluematt.me>
<CANEZrP3wGWHdz+ut6pvke5TJJsc1rTFt8sn2KziX35oL5LAsyg@mail.gmail.com>
<CABm2gDpDvk2VsQ+mJ-BoeBKmvu9jBXNujZEFKuCStRNjFL6VOA@mail.gmail.com>
<CANEZrP2zAGCCBhNa4=9yw+A_Dn5o4SQXoPTE_qcJzZ1dFuF2tw@mail.gmail.com>
<CABm2gDqd6iHRUDKZWWTudcC1QkYa+rCuHjz7pMC2K1Db8wpgfA@mail.gmail.com>
<CANEZrP1CU0kB0vXeXUX1L8byaT-Zf2xg+3N+GeNthi_i6bn1qw@mail.gmail.com>
<CABm2gDpgBNjuPLnFiU2TspgLws7JjWnsxih09JG9bQycraS=sQ@mail.gmail.com>
<CANEZrP1ay64jryeUyDJ9Y+1C-Bre1U_1xMyuB4cqQprd1-qbCA@mail.gmail.com>
<CABm2gDq12a8p8+fB14nM5S8CVz=sdESMowZJUeKBwvx16WDSDQ@mail.gmail.com>
<CABsx9T1nwastEoN12B2Y-TA2V1fYtDcm9-nkiOQNVhXmbCjcGQ@mail.gmail.com>
Date: Thu, 7 May 2015 20:05:22 +0200
Message-ID: <CABm2gDoF=JPOV=FqWBzXFp21=mJc4jJHGDKb1b5PYx28rGqeSw@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-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1YqQAq-00020n-Qk
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Block Size Increase
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 07 May 2015 18:05:30 -0000
On Thu, May 7, 2015 at 6:59 PM, Gavin Andresen <gavinandresen@gmail.com> wr=
ote:
> Fee dynamics seems to come up over and over again in these discussions, w=
ith
> lots of talk and theorizing.
>
> I hope some data on what is happening with fees right now might help, so =
I
> wrote another blog post (with graphs, which can't be done in a mailing li=
st
> post):
> http://gavinandresen.ninja/the-myth-of-not-full-blocks
>
> We don=E2=80=99t need 100% full one megabyte blocks to start to learn abo=
ut what is
> likely to happen as transaction volume rises and/or the one megabyte bloc=
k
> size limit is raised.
Ok, the fact that the fee increases the probability of getting
included faster already is a good thing, the graphs with the
probability of getting included in the next block were less important
to me.
Although scarce space (beyond what miners chose to limit by
themselves) would increase the fee competition, I didn't knew that
there is actually some competition happening already.
So I guess this diminishes the argument for maintaining the limits
longer to observe the results of more scarce space.
Still, I think maintaining a lower policy limit it's a good idea, even
if we decide not to use it to observe that soon.
For example, say we chose the 20 MB consensus limit, we can maintain
the policy limit at 1 MB or move it to 2 MB, and slowly moving it up
later as needed without requiring everyone to upgrade.
Of course, not all miners have to follow the standard policy, but at
least it's something.
So please take this as a suggestion to improve your proposal. You can
argue it like this "if we want to maintain the limits after the
hardfork or increase them slowly, for observing fee dynamics with more
scarce space or for any other reason, those limits can be partially
enforced by the standard policy". I mean, I think that could be a
reasonable compromise for that concrete line of arguments.
|
