Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 1F58F953 for ; Thu, 12 Nov 2015 21:27:20 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id BDC0516E for ; Thu, 12 Nov 2015 21:27:19 +0000 (UTC) Received: from ishibashi.localnet (unknown [IPv6:2001:470:5:265:61b6:56a6:b03d:28d6]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id 5790138A6EAE; Thu, 12 Nov 2015 21:26:46 +0000 (UTC) X-Hashcash: 1:25:151112:morcos@gmail.com::cZt506EEBxQz/TaL:a/8Bd X-Hashcash: 1:25:151112:jtimon@jtimon.cc::nRU9hOPPFyhqx2qZ:a=x=C X-Hashcash: 1:25:151112:bitcoin-dev@lists.linuxfoundation.org::rliA3mTVkaQNRrxd:atRbc From: Luke Dashjr To: Alex Morcos Date: Thu, 12 Nov 2015 21:26:38 +0000 User-Agent: KMail/1.13.7 (Linux/4.1.9-gentoo-r1; KDE/4.14.8; x86_64; ; ) References: <5644ECE6.9090304@mattcorallo.com> <201511122110.47665.luke@dashjr.org> In-Reply-To: X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F X-PGP-Key-ID: BD02942421F4889F X-PGP-Keyserver: hkp://pgp.mit.edu MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201511122126.39532.luke@dashjr.org> X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD 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] 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 21:27:20 -0000 On Thursday, November 12, 2015 9:21:57 PM Alex Morcos wrote: > To be clear Luke, its not THAT complicated to maintain the mining policy, > but preserving the ability of people to place priority based transactions > in a limited mempool world is quite complicated. See recently closed > #6992. > I think the biggest issue with #6357 is being sure the logic doesn't break > in future changes. There are a lot of things that need to be updated in > the right order when blocks are connected or disconnected. That's what unit tests are for. :) > And whats the point of having even that added extra complication if its not > easy to place free transactions and starting priority is a decent > approximation for mining anyway (txs can just be rebroadcast in the worst > case). I'm not sure what you're getting at here, but rebroadcasting won't work if they're still in the memory pools (unless we open the door to DoS from reprocessing the same tx over and over). Luke