Re: [Bitcoin-development] Proposal: SPV Fee Discovery mechanism

[Tom Harding <tomh@thinlink.com>]

On 6/11/2015 6:10 AM, Peter Todd wrote:
> On Wed, Jun 10, 2015 at 02:18:30PM -0700, Aaron Voisine wrote:
>> The other complication is that this will tend to be a lagging indicator
>> based on network congestion from the last time you connected. If we assume
>> that transactions are being dropped in an unpredictable way when blocks are
>> full, knowing the network congestion *right now* is critical, and even then
>> you just have to hope that someone who wants that space more than you do
>> doesn't show up after you disconnect.
> Hence the need for ways to increase fees on transactions after initial
> broadcast like replace-by-fee and child-pays-for-parent.
>
> Re: "dropped in an unpredictable way" - transactions would be dropped
> lowest fee/KB first, a completely predictable way.

Quite agreed.  Also, transactions with unconfirmed inputs should be 
among the first to get dropped, as discussed in the "Dropped-transaction 
spam" thread.  Like all policy rules, either of these works in 
proportion to its deployment.

Be advised that pull request #6068 emphasizes the view that the network 
will never have consistent mempool/relay policies, and on the contrary 
needs a framework that supports and encourages pluggable, generally 
parameterized policies that could (some might say should) conflict 
wildly with each other.

It probably doesn't matter that much.  Deploying a new policy still 
wouldn't be much easier than deploying a patched version.  I mean, 
nobody has proposed a policy rule engine yet (oops).