Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id B3C80895 for ; 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 ; Tue, 11 Aug 2015 17:03:29 +0000 (UTC) Received: by wicne3 with SMTP id ne3so69425956wic.0 for ; 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: References: <1905570.ujI5LhNI6Z@coldstorage> Date: Tue, 11 Aug 2015 19:03:27 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Dave Scotese 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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


On Aug 9, 2015 10:44 PM, "Dave Scotese via bitcoin-dev" <bitcoin-dev@lists.linux= foundation.org> wrote:
>
> On Sun, Aug 9, 2015 at 3:42 AM, Thomas Zander via bitcoin-dev <bitcoin-dev@lists.linu= xfoundation.org> wrote:
>>
>> On Saturday 8. August 2015 15.45.28 Dave Scotese via bitcoin-dev w= rote:
>> > Someone mentioned that when the backlog grows faster than it = shrinks, that
>> > is a real problem.=C2=A0 I don't think it is.=C2=A0 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 does= n't cope
>> well with a continuously growing mempool.
>> If Bitcoind starts eating more and more memory, I expect lots of p= eople that
>> run it now to turn it off.
>
>
> 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.

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:
https://github.com= /bitcoin/bitcoin/pull/6470

--f46d0418271eb916e5051d0c1470--