From: Luke Dashjr <luke@dashjr.org>
To: Alex Morcos <morcos@gmail.com>
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>
	<CAPWm=eXNFimrG1A7bxJ3i=w_iWm57r93bjfiGZwq9y8KbZ8+Qg@mail.gmail.com>
In-Reply-To: <CAPWm=eXNFimrG1A7bxJ3i=w_iWm57r93bjfiGZwq9y8KbZ8+Qg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201511122126.39532.luke@dashjr.org>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Upcoming Transaction Priority Changes
Precedence: list

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