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
|
Return-Path: <mark@friedenbach.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 68DA1AE7
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 24 Jun 2015 02:15:57 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com
[209.85.213.173])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9AC28F4
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 24 Jun 2015 02:15:56 +0000 (UTC)
Received: by igin14 with SMTP id n14so24848639igi.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 23 Jun 2015 19:15:56 -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;
bh=fhMWAv9yFTBqd/YuaRnKyxvxKdhLXCBlA9qoQEQfps8=;
b=DTnUPNmjL2suXKuNs4hr6GrhUCK5NIu12bZ8rY5M9WG4Zs8vKoeb9cL2m8gjfqKT5i
6opN27/FaaXsLhJOdNvawcZftzs39yU+Ga4J9pnDgk8ikS7Duz1YLIsnkWHUyAXmfQQk
D8N3xS75zoHx1q0+UAl85uLTfm5o3eP+8+I3ysXgD5lpaY+noNUfCLQPRDpTOui2sCYP
tcfsfhldrS0vPmsNtGgp3MHJvBpEEUwYL9PUAugnVpTcpTxiCMxQY5XvT+6lLF4g+lFo
iQ3SEG4Qi9MmH0kAoxpQdUuSHe5C3KPJgAhgHpPXxkaGlkvjDNI2nPIKzMdu8MbkjAOd
xSyQ==
X-Gm-Message-State: ALoCoQlsNClx57xgpOBDKWzQ9bZBr98iVixFmW5KJ50eNxSUhEG5EXFCA4AUtw1DqI58HSOACBRF
MIME-Version: 1.0
X-Received: by 10.107.3.227 with SMTP id e96mr14933907ioi.50.1435112156146;
Tue, 23 Jun 2015 19:15:56 -0700 (PDT)
Received: by 10.107.149.20 with HTTP; Tue, 23 Jun 2015 19:15:55 -0700 (PDT)
X-Originating-IP: [172.56.16.75]
Received: by 10.107.149.20 with HTTP; Tue, 23 Jun 2015 19:15:55 -0700 (PDT)
In-Reply-To: <558A0FCB.2040908@ktorn.com>
References: <558A0FCB.2040908@ktorn.com>
Date: Tue, 23 Jun 2015 19:15:55 -0700
Message-ID: <CAOG=w-vj8LQjun0u03nWRz1RV7NMw=ALdQkbiQcrOb=cpfWZZg@mail.gmail.com>
From: Mark Friedenbach <mark@friedenbach.org>
To: Filipe Farinha <filipe@ktorn.com>
Content-Type: multipart/alternative; boundary=001a113f0c5a48012905193a1618
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE,
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@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Mempool size consensus + dynamic block size
re-targetting
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: Wed, 24 Jun 2015 02:15:57 -0000
--001a113f0c5a48012905193a1618
Content-Type: text/plain; charset=UTF-8
Anyone could lie.
On Jun 23, 2015 7:12 PM, "Filipe Farinha" <filipe@ktorn.com> wrote:
> To my knowledge so far the main proposals regarding block size changes are
> either based on predictions, which traditionally we're not very good at, or
> a voting mechanism by a limited set of stakeholders (miners) whose
> interests may not be aligned with the rest of the community.
>
> Neither strategy takes into account the most important factor: real-time
> changes to the mempool. This is for a valid reason, there is currently no
> consensus on the size of the mempool.
>
> So my question is: has anyone considered the pros and cons of creating
> consensus around the current (approximate) mempool size?
>
> I propose that, at the expense of some transaction overhead (3 or 4 extra
> bytes?), each full-node that broadcasts a new transaction can add a
> mempool_size field that represents their current view of the mempool. As
> blocks are mined with this new data (which may or not be aggregated in the
> block header), all nodes can quickly reach consensus on the current
> average/median/etc mempool size, and agree on a suitable periodic blocksize
> "re-targetting" (similarly to mining difficulty).
>
> Since all full-nodes (not just miners) get to vote with their transactions
> the consensus is truly global, and we don't have to change blocksize
> blindly in anticipation of an unpredictable future.
>
> Would this not work, and if not, why?
>
> Filipe Farinha
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--001a113f0c5a48012905193a1618
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">Anyone could lie.</p>
<div class=3D"gmail_quote">On Jun 23, 2015 7:12 PM, "Filipe Farinha&qu=
ot; <<a href=3D"mailto:filipe@ktorn.com">filipe@ktorn.com</a>> wrote:=
<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">To my knowledge so =
far the main proposals regarding block size changes are either based on pre=
dictions, which traditionally we're not very good at, or a voting mecha=
nism by a limited set of stakeholders (miners) whose interests may not be a=
ligned with the rest of the community.<br>
<br>
Neither strategy takes into account the most important factor: real-time ch=
anges to the mempool. This is for a valid reason, there is currently no con=
sensus on the size of the mempool.<br>
<br>
So my question is: has anyone considered the pros and cons of creating cons=
ensus around the current (approximate) mempool size?<br>
<br>
I propose that, at the expense of some transaction overhead (3 or 4 extra b=
ytes?), each full-node that broadcasts a new transaction can add a mempool_=
size field that represents their current view of the mempool. As blocks are=
mined with this new data (which may or not be aggregated in the block head=
er), all nodes can quickly reach consensus on the current average/median/et=
c mempool size, and agree on a suitable periodic blocksize "re-targett=
ing" (similarly to mining difficulty).<br>
<br>
Since all full-nodes (not just miners) get to vote with their transactions =
the consensus is truly global, and we don't have to change blocksize bl=
indly in anticipation of an unpredictable future.<br>
<br>
Would this not work, and if not, why?<br>
<br>
Filipe Farinha<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
--001a113f0c5a48012905193a1618--
|
