MIME-Version: 1.0
In-Reply-To: <201511122012.29966.luke@dashjr.org>
References: <5644ECE6.9090304@mattcorallo.com>
	<201511122012.29966.luke@dashjr.org>
Date: Thu, 12 Nov 2015 21:43:17 +0100
Message-ID: <CABm2gDqnmR5eAEZj_CRJ6Q5gi8LM_chb3tBCt2=L9ojr+Ziadw@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Luke Dashjr <luke@dashjr.org>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Upcoming Transaction Priority Changes
Precedence: list

On Thu, Nov 12, 2015 at 9:12 PM, Luke Dashjr via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Thursday, November 12, 2015 7:47:50 PM Matt Corallo via bitcoin-dev wrote:
>>  * Mining code will use starting priority for ease of implementation
>
> This should be optional, at least for 0.12.

The ease of implementation is not gained if it's maintained optionally.

>>  * Default block priority size will be 0
>
> We should not be influencing miner policy by changing defaults.

I agree changing policy defaults is meaningless, but in this case it
is supposed to signal deprecation of the policy option.

On Thu, Nov 12, 2015 at 9:20 PM, Chun Wang via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> I would think about to merge the priority, feerate, and probably
> sigoprate into one number, probably 576 priorities trade for 1 satoshi
> per kb?

I am in favor of having customizable cost (currently tx size but it
has been proposed to also include sigoprate) and reward (currently
feerate). The main problem I see for keep maintaining the code is that
priority is not integrated in the reward function and cannot easily be
with its current functionality unchanged (which slows down other very
necessary improvements in the mempool limits).