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 1A9EA405 for ; Thu, 12 Nov 2015 19:47:54 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.bluematt.me (mail.bluematt.me [192.241.179.72]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BE94D233 for ; Thu, 12 Nov 2015 19:47:53 +0000 (UTC) Received: from [172.17.0.1] (gw.vpn.bluematt.me [162.243.132.6]) by mail.bluematt.me (Postfix) with ESMTPSA id 3504159E7F for ; Thu, 12 Nov 2015 19:47:52 +0000 (UTC) To: bitcoin-dev@lists.linuxfoundation.org From: Matt Corallo X-Enigmail-Draft-Status: N1110 Message-ID: <5644ECE6.9090304@mattcorallo.com> Date: Thu, 12 Nov 2015 19:47:50 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: [bitcoin-dev] Upcoming Transaction Priority Changes 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: Thu, 12 Nov 2015 19:47:54 -0000 On the IRC meeting today there was a long discussion on how to handle the old "transaction priority" stuff in 0.12. Over time the "transaction priority" stuff has added a huge amount of code and taken a bunch of otherwise-useful developer effort. There is still some debate about its usefulness going forward, but there was general agreement that it will either be removed entirely or replaced with something a bit less costly to maintain some time around 0.13. With the mempool limiting stuff already in git master, high-priority relay is disabled when mempools are full. In addition, there was agreement to take the following steps for 0.12: * Mining code will use starting priority for ease of implementation * Default block priority size will be 0 * Wallet will no longer create 0-fee transactions when mempool limiting is in effect. What this means for you is, essentially, be more careful when relying on priority to mine your transactions. If mempools are full, your transactions will be increasingly less likely to be relayed and more miners may start disabling high-priority block space. Make sure you analyze previous blocks to determine if high-priority mining is still enabled and ensure your transactions will be relayed. Matt