Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of datamagi.no
	designates 80.65.61.66 as permitted sender)
	client-ip=80.65.61.66; envelope-from=martin@datamagi.no;
	helo=srv3.datamagi.no; 
Message-ID: <55799727.7090902@datamagi.no>
Date: Thu, 11 Jun 2015 16:11:51 +0200
From: Martin Lie <martin@datamagi.no>
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 Dev <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=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Bitcoin-development] Proposal: SPV Fee Discovery mechanism
Precedence: list

Peter Todd wrote:
> Re: "dropped in an unpredictable way" - transactions would be dropped
> lowest fee/KB first, a completely predictable way.

It would be 'completely predictable' for whoever knew the state and 
policies of a miner's mempool, but from an end user's perspective that 
wouldn't matter much: The end users wouldn't know if their 
transaction(s) would make the cut or not, somewhere in the network, and 
by what time. They (obviously) won't know what miners will find the next 
block(s), they won't know the miners' mempool sizes, potential custom 
eviction policies, etc.

I agree that this can be somewhat remedied by FSSRBF/CPFP, though, 
provided wallets give users a good (semi-automated?) interface for such 
transaction replacements/chains.


-- 
Martin Lie