[bitcoin-dev] Upcoming Transaction Priority Changes

[bitcoin-dev] Upcoming Transaction Priority Changes

[Matt Corallo]

On the IRC meeting today there was a long discussion on how to handle
the old "transaction priority" stuff in 0.12. Over time the "transaction
priority" stuff has added a huge amount of code and taken a bunch of
otherwise-useful developer effort. There is still some debate about its
usefulness going forward, but there was general agreement that it will
either be removed entirely or replaced with something a bit less costly
to maintain some time around 0.13.

With the mempool limiting stuff already in git master, high-priority
relay is disabled when mempools are full. In addition, there was
agreement to take the following steps for 0.12:

 * Mining code will use starting priority for ease of implementation
 * Default block priority size will be 0
 * Wallet will no longer create 0-fee transactions when mempool limiting
is in effect.

What this means for you is, essentially, be more careful when relying on
priority to mine your transactions. If mempools are full, your
transactions will be increasingly less likely to be relayed and more
miners may start disabling high-priority block space. Make sure you
analyze previous blocks to determine if high-priority mining is still
enabled and ensure your transactions will be relayed.

Matt

Re: [bitcoin-dev] Upcoming Transaction Priority Changes

[Luke Dashjr]

On Thursday, November 12, 2015 7:47:50 PM Matt Corallo via bitcoin-dev wrote:
> With the mempool limiting stuff already in git master, high-priority
> relay is disabled when mempools are full. In addition, there was
> agreement to take the following steps for 0.12:
> 
>  * Mining code will use starting priority for ease of implementation

This should be optional, at least for 0.12.

>  * Default block priority size will be 0

We should not be influencing miner policy by changing defaults.

Luke

Re: [bitcoin-dev] Upcoming Transaction Priority Changes

[Chun Wang]

I doubt changing the default value is useful as casual mining had long
dead, and pools all have their own customized policies. But I think
change the priority size to 0 is the right way to do. The sort by
priority part in the block is always the best place for spam nowadays.
I would think about to merge the priority, feerate, and probably
sigoprate into one number, probably 576 priorities trade for 1 satoshi
per kb?

On Fri, Nov 13, 2015 at 4:12 AM, 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:
>> With the mempool limiting stuff already in git master, high-priority
>> relay is disabled when mempools are full. In addition, there was
>> agreement to take the following steps for 0.12:
>>
>>  * Mining code will use starting priority for ease of implementation
>
> This should be optional, at least for 0.12.
>
>>  * Default block priority size will be 0
>
> We should not be influencing miner policy by changing defaults.
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Upcoming Transaction Priority Changes

[Luke Dashjr]

On Thursday, November 12, 2015 8:20:45 PM Chun Wang wrote:
> The sort by priority part in the block is always the best place for spam
> nowadays.

What are you saying here? Spammers generally can't use the priority space at 
all, and it is a major way for legitimate users to get their transactions 
mined cheaply despite ongoing spam attempts. You're suggesting the exact 
opposite is true?? Please explain.

Luke

Re: [bitcoin-dev] Upcoming Transaction Priority Changes

[James Hilliard]

[-- Attachment #1: Type: text/plain, Size: 1212 bytes --]

The priority space is causing major mempool bloating and GBT latency right
now since many of the free transactions aren't getting mined and cleared
out of the mempool anymore. From my testing setting minrelaytxfee=0.0001 is
not enough to prevent the mempool from getting large during a spam attack,
it is also necessary to set limitfreerelay=0 in order to prevent GBT
latency degradation. Without setting limitfreerelay=0 GBT degrades
significantly for every hour bitcoind is running.

On Thu, Nov 12, 2015 at 2:25 PM, Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Thursday, November 12, 2015 8:20:45 PM Chun Wang wrote:
> > The sort by priority part in the block is always the best place for spam
> > nowadays.
>
> What are you saying here? Spammers generally can't use the priority space
> at
> all, and it is a major way for legitimate users to get their transactions
> mined cheaply despite ongoing spam attempts. You're suggesting the exact
> opposite is true?? Please explain.
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 1824 bytes --]

Re: [bitcoin-dev] Upcoming Transaction Priority Changes

[Jorge Timón]

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

Re: [bitcoin-dev] Upcoming Transaction Priority Changes

[Luke Dashjr]

On Thursday, November 12, 2015 8:43:17 PM Jorge Timón wrote:
> 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.

It has come to my attention maintaining the current priority algorithm is not 
even expensive, so I think I'm inclined to NACK using starting priority 
altogether. Since I am the mining maintainer for Core, I believe it's 
reasonable for me to decide on maintenance tradeoffs...

Therefore, my goal in this matter will be to review #6357 in depth to be 
merged, and follow up with #6898 based on the current default policies.

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

This is a bad idea anyway, since priority is the best metric we have right now 
for ensuring legitimate transactions get mined despite spam attacks.

Luke

Re: [bitcoin-dev] Upcoming Transaction Priority Changes

[Alex Morcos]

[-- Attachment #1: Type: text/plain, Size: 2353 bytes --]

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


On Thu, Nov 12, 2015 at 4:10 PM, Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Thursday, November 12, 2015 8:43:17 PM Jorge Timón wrote:
> > 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.
>
> It has come to my attention maintaining the current priority algorithm is
> not
> even expensive, so I think I'm inclined to NACK using starting priority
> altogether. Since I am the mining maintainer for Core, I believe it's
> reasonable for me to decide on maintenance tradeoffs...
>
> Therefore, my goal in this matter will be to review #6357 in depth to be
> merged, and follow up with #6898 based on the current default policies.
>
> > >>  * 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.
>
> This is a bad idea anyway, since priority is the best metric we have right
> now
> for ensuring legitimate transactions get mined despite spam attacks.
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 3173 bytes --]

Re: [bitcoin-dev] Upcoming Transaction Priority Changes

[Luke Dashjr]

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