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 4EAC5FF for ; Sun, 9 Aug 2015 10:42:56 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from manxnetsf05.manx.net (outbound.manx.net [213.137.31.12]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8A2F218D for ; Sun, 9 Aug 2015 10:42:55 +0000 (UTC) Received: from adsl92.39.203.140.manx.net (EHLO coldstorage.localnet) ([92.39.203.140]) by manxnetsf05.manx.net (MOS 4.4.5a-GA FastPath queued) with ESMTP id EFZ43295; Sun, 09 Aug 2015 11:42:53 +0100 (BST) From: Thomas Zander To: Bitcoin Dev Date: Sun, 09 Aug 2015 12:42:53 +0200 Message-ID: <1905570.ujI5LhNI6Z@coldstorage> User-Agent: KMail/4.14.1 (Linux/3.16.0-4-amd64; KDE/4.14.2; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Mirapoint-Received-SPF: 92.39.203.140 coldstorage.localnet thomas@thomaszander.se 5 none X-Junkmail-Status: score=10/50, host=manxnetsf05.manx.net X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0204.55C72EAD.0137, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2014-07-29 09:23:55, dmn=2013-03-21 17:37:32, mode=multiengine X-Junkmail-IWF: false X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0204.55C72EAD.0137, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2014-07-29 09:23:55, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 1d0b4c36cb3b39a7afaf456daeb455b9 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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 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 10:42:56 -0000 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. > 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. Actually, we didn't teach people anything, we told wallet developers to do it. Most actual users were completely ignorant of the problem. Full blocks will then stop being a supported usecase when real humans are trying to buy a beer or a coffee. Waiting for a confirmation won't work either for the vast majority of the current usages of Bitcoin in the real world. > I am comfortable leaving those zero-conf people in a little bit > of trouble. 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. -- Thomas Zander