Message-ID: <5579C0FE.8080701@thinlink.com>
Date: Thu, 11 Jun 2015 10:10:22 -0700
From: Tom Harding <tomh@thinlink.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <CAFdHNGgtgWGu8gnnJfM0EcVn2m_Wff5HPwAe-9FBvjR++q0Q-Q@mail.gmail.com>	<CANEZrP3+jW3BO=Zv41CGubJL7bSZ==o=Wp83K6Q0xL4PP+0ZUQ@mail.gmail.com>	<CACq0ZD6Qr7F7_20Nfd0a8TTHEVMR0fxu-T5bO4FfN1Lp9PcGDQ@mail.gmail.com>
	<20150611131048.GA24053@savin.petertodd.org>
In-Reply-To: <20150611131048.GA24053@savin.petertodd.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Bitcoin-development] Proposal: SPV Fee Discovery mechanism
Precedence: list

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).