From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 0BAB48A7 for ; Sun, 9 Aug 2015 20:43:51 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CBE9E17B for ; Sun, 9 Aug 2015 20:43:49 +0000 (UTC) Received: by wicja10 with SMTP id ja10so15784358wic.1 for ; Sun, 09 Aug 2015 13:43:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=p93UHjJtlGO+ItxKsVEvx3U0msp9616bXCxCp94Gwu4=; b=Ojaezy6jn2DblvKv4VkX0hUACA9SGN4oLKgHONFJIcApSFTeKz651wRXnuq4shd/2i QcA2sONpyMCyTyjgx2NqnhsVURJVAa7f4PcuYDF6+/w0VngQhyyJt/WUosqvv86OdXEP Xd/L5DC687QmTiI04+42SBKEFLyE6WunnT7X8ZYtGurCvaUkl+Xga2GnkywIVRIW9wmV ce6+rtTR8AAgmhxf7b4KtmZokXvpAghEgVQcZksPAm9WPa/aeabADYzhaybCXX5SXb8h lOfcMx2UHk5hVL17DTziQbi2U8mFiA4bCYtgD90n4qVm/ti1zCTDqlkWCwJD66bC7BXU eDzg== MIME-Version: 1.0 X-Received: by 10.180.76.232 with SMTP id n8mr18607619wiw.72.1439153028500; Sun, 09 Aug 2015 13:43:48 -0700 (PDT) Sender: dscotese@gmail.com Received: by 10.27.184.134 with HTTP; Sun, 9 Aug 2015 13:43:48 -0700 (PDT) In-Reply-To: <1905570.ujI5LhNI6Z@coldstorage> References: <1905570.ujI5LhNI6Z@coldstorage> Date: Sun, 9 Aug 2015 13:43:48 -0700 X-Google-Sender-Auth: ylw4rzsobICe74aNBB_yTm0fKEI Message-ID: From: Dave Scotese To: Thomas Zander Content-Type: multipart/alternative; boundary=f46d043893f90a943c051ce6edf3 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,FREEMAIL_FROM,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: Sun, 09 Aug 2015 20:43:51 -0000 --f46d043893f90a943c051ce6edf3 Content-Type: text/plain; charset=UTF-8 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. > > but backlogs in the past have already > > started training users to wait for at least one confirmation, or go > > off-chain. > > I am wondering how you concluded that? The only time we saw full blocks > for a > considerable amount of time was when we had a spammer, and the only thing > we taught people was to use higher fees. > I concluded that because I don't think I'm all that different than others, and that is what I have done. The "training" of which I speak is not always recognized by the bitcoiner on whom it operates. A similar "training" is how we all learn to ignore teachers because governments force our attendance at school. > > Everyone else can double-spend (perhaps that's not as easy as > > it should be in bitcoin core) and use a higher fee, thus competing for > > block space. > > This is false, if you want to double spent you have to do a lot of work and > have non-standard software. For instance sending your newer transaction > to a > random node will almost always get it rejected because its a double spent. > Replace by fee (even safe) is not supported in the vast majority of Bitcoin > land. > I don't know what you meant to say is false. I agree with the other stuff you wrote. Thanks for confirming that it is difficult. I did some research on replace by fee (FSS-RBF) and on Child-pays-for-parent (CPFP). You point out that these solutions to paying too-low fees are "not supported in the vast majority...". Do you mean philosophically or programmatically? The trend seems to me toward improvements, just as I insinuated may be necessary ("perhaps that's not as easy as it should be in bitcoin core"), so, once again, I have to reiterate that transaction backlog has valuable solutions other than increasing the block size. I also realized that we have already been through a period of full blocks, so that tremendously reduces the value I see in doing it again. It was that "spam" test someone ran that did it for us, and I love that. It seems to have kicked the fee-increasability efforts in the butt, which is great. I now place a higher priority on enabling senders to increase their fee when necessary than on increasing the Txns per second that the network can handle. The competition between these two is rather unfair because of how easy it is to apply the "N MB-blocks bandaid". Dave --f46d043893f90a943c051ce6edf3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Aug 9, 2015 at 3:42 AM, Thomas Zander vi= a bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
On Saturday 8. August 2015 15.45.28 Dave Scotese via bitc= oin-dev wrote:
> 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 proble= m for those who
> don't wait for even one confirmation

The mention you refer to was about the fact that the software doesn't c= ope
well with a continuously growing mempool.
If Bitcoind starts eating more and more memory, I expect lots of people tha= t
run it now to turn it off.

That is a re= al problem then.=C2=A0 While emptying the mempool faster with bigger blocks= will help to reduce the occurrence of that problem, I propose a user-confi= gurable default limit to the size of the mempool as a permanent solution re= gardless of block size.=C2=A0 "This software has stopped consuming mem= ory necessary to validate transactions.=C2=A0 You can override this by ...&= quot;=C2=A0 If anyone feels that protecting those running full nodes from b= itcoind eating more and more memory this way is a good idea, I can make a B= IP out of it if that would help.

> Everyone else can double-spend (perhaps that's not as easy as
> it should be in bitcoin core) and use a higher fee, thus competing for=
> block space.

This is false, if you want to double spent you have to do a lot of work and=
have non-standard software.=C2=A0 For instance sending your newer transacti= on to a
random node will almost always get it rejected because its a double spent.<= br> Replace by fee (even safe) is not supported in the vast majority of Bitcoin=
land.

I don't know what you meant to say is false.=C2=A0 I agree w= ith the other stuff you wrote.=C2=A0 Thanks for confirming that it is diffi= cult.

I did some research on replac= e by fee (FSS-RBF) and on Child-pays-for-parent (CPFP).=C2=A0 You point out= that these solutions to paying too-low fees are "not supported in the= vast majority...".=C2=A0 Do you mean philosophically or programmatica= lly?=C2=A0 The trend seems to me toward improvements, just as I insinuated = may be necessary ("perhaps that's not as easy as it should be in b= itcoin core"), so, once again, I have to reiterate that transaction ba= cklog has valuable solutions other than increasing the block size.
I also realized that we have already been through a period of full b= locks, so that tremendously reduces the value I see in doing it again.=C2= =A0 It was that "spam" test someone ran that did it for us, and I= love that.=C2=A0 It seems to have kicked the fee-increasability efforts in= the butt, which is great.

I now place a higher priority on enabling= senders to increase their fee when necessary than on increasing the Txns p= er second that the network can handle.=C2=A0 The competition between these = two is rather unfair because of how easy it is to apply the "N MB-bloc= ks bandaid".

Dave
--f46d043893f90a943c051ce6edf3--