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: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id B3C80895
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 11 Aug 2015 17:03:30 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com
[209.85.212.173])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 63DEB109
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 11 Aug 2015 17:03:29 +0000 (UTC)
Received: by wicne3 with SMTP id ne3so69425956wic.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 11 Aug 2015 10:03:28 -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=BSA8QoNzhmhhc30sZODW8eW1zyf0+UrDZuqU72L+hKs=;
b=HcqvFz6TImoTLm10lT9wnQ6y0MryToEqq1k64OSJrC3Z1vECNXu8Q5nYYMLQ8UqCWD
/KF0+aHcuNZ+oqOf5MpmQW0e4f7v+KasCb+LX75XUkE9saVM2He89eN/ckXh3kNZ0nWw
AVaMhnrX2CV0PiJ2u0PqBly8+fU3ViW52l2n2TnwuM7wHN27/NygTRptgFnfNGHjjkWu
+61OeHUWR/tY7wg4MQYIYwYClleR+aOdQI1fZEXmfiXIMXk+W+rr1xazrBG2n2GmhOml
nCT3myJIhZD2MCBK0Z6QnWGW2kJqJWcCRyF0Z6LXuhSTzhz4T7CcC8HObky08T99C5T9
pY+w==
X-Gm-Message-State: ALoCoQmx96L9Bpb1LZEOz41LbTIdnra+CS2dfm6POjBlipcHCkzstEHWKEa8GvDMWSVmFZ5JoOvv
MIME-Version: 1.0
X-Received: by 10.180.8.135 with SMTP id r7mr38699492wia.58.1439312608034;
Tue, 11 Aug 2015 10:03:28 -0700 (PDT)
Received: by 10.194.31.230 with HTTP; Tue, 11 Aug 2015 10:03:27 -0700 (PDT)
Received: by 10.194.31.230 with HTTP; Tue, 11 Aug 2015 10:03:27 -0700 (PDT)
In-Reply-To: <CAGLBAhd7s4QoXDfyxCACuVXPA-dRzULuiiW_1AVO0o4_jO8TyQ@mail.gmail.com>
References: <CABsx9T16fH+56isq95m4+QWsKwP==tf75ep8ghnEcBoV4OtZJA@mail.gmail.com>
<CALqxMTGDET0dEuw9bi=LBXF8jiuLdoPoGYaDCPpXtPvqeDW30A@mail.gmail.com>
<CAGLBAhcfUv0ptwczgCkgwVxo7d=pK4GLowkwV2viqAbq6vRaDQ@mail.gmail.com>
<1905570.ujI5LhNI6Z@coldstorage>
<CAGLBAhd7s4QoXDfyxCACuVXPA-dRzULuiiW_1AVO0o4_jO8TyQ@mail.gmail.com>
Date: Tue, 11 Aug 2015 19:03:27 +0200
Message-ID: <CABm2gDrUBY_1oG=W=sFVqH_XhxGBOVncS0VJBekmK4mQOSKLew@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Dave Scotese <dscotese@litmocracy.com>
Content-Type: multipart/alternative; boundary=f46d0418271eb916e5051d0c1470
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 <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Fees and the block-finding process
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: Tue, 11 Aug 2015 17:03:30 -0000
--f46d0418271eb916e5051d0c1470
Content-Type: text/plain; charset=UTF-8
On Aug 9, 2015 10:44 PM, "Dave Scotese via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> On Sun, Aug 9, 2015 at 3:42 AM, Thomas Zander via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> On Saturday 8. August 2015 15.45.28 Dave Scotese via bitcoin-dev wrote:
>> > Someone mentioned that when the backlog grows faster than it shrinks,
that
>> > is a real problem. I don't think it is. It is a problem for those who
>> > don't wait for even one confirmation
>>
>> The mention you refer to was about the fact that the software doesn't
cope
>> well with a continuously growing mempool.
>> If Bitcoind starts eating more and more memory, I expect lots of people
that
>> run it now to turn it off.
>
>
> That is a real problem then. While emptying the mempool faster with
bigger blocks will help to reduce the occurrence of that problem, I propose
a user-configurable default limit to the size of the mempool as a permanent
solution regardless of block size. "This software has stopped consuming
memory necessary to validate transactions. You can override this by ..."
If anyone feels that protecting those running full nodes from bitcoind
eating more and more memory this way is a good idea, I can make a BIP out
of it if that would help.
You are completely right: this problem has nothing to do with the consensus
block size maximum and it has to be solved regardless of what the maximum
is. No BIP is necessary for this. The "doing nothing side" has been working
on this too:
https://github.com/bitcoin/bitcoin/pull/6470
--f46d0418271eb916e5051d0c1470
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
On Aug 9, 2015 10:44 PM, "Dave Scotese via bitcoin-dev" <<a hr=
ef=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linux=
foundation.org</a>> wrote:<br>
><br>
> On Sun, Aug 9, 2015 at 3:42 AM, Thomas Zander via bitcoin-dev <<a h=
ref=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linu=
xfoundation.org</a>> wrote:<br>
>><br>
>> On Saturday 8. August 2015 15.45.28 Dave Scotese via bitcoin-dev w=
rote:<br>
>> > Someone mentioned that when the backlog grows faster than it =
shrinks, that<br>
>> > is a real problem.=C2=A0 I don't think it is.=C2=A0 It is=
a problem for those who<br>
>> > don't wait for even one confirmation<br>
>><br>
>> The mention you refer to was about the fact that the software does=
n't cope<br>
>> well with a continuously growing mempool.<br>
>> If Bitcoind starts eating more and more memory, I expect lots of p=
eople that<br>
>> run it now to turn it off.<br>
><br>
><br>
> That is a real problem then.=C2=A0 While emptying the mempool faster w=
ith bigger blocks will help to reduce the occurrence of that problem, I pro=
pose a user-configurable default limit to the size of the mempool as a perm=
anent solution regardless of block size.=C2=A0 "This software has stop=
ped consuming memory necessary to validate transactions.=C2=A0 You can over=
ride this by ..."=C2=A0 If anyone feels that protecting those running =
full nodes from bitcoind eating more and more memory this way is a good ide=
a, I can make a BIP out of it if that would help.</p>
<p dir=3D"ltr">You are completely right: this problem has nothing to do wit=
h the consensus block size maximum and it has to be solved regardless of wh=
at the maximum is. No BIP is necessary for this. The "doing nothing si=
de" has been working on this too: <br>
<a href=3D"https://github.com/bitcoin/bitcoin/pull/6470">https://github.com=
/bitcoin/bitcoin/pull/6470</a></p>
--f46d0418271eb916e5051d0c1470--
|
