* [bitcoin-dev] Upcoming Transaction Priority Changes
@ 2015-11-12 19:47 Matt Corallo
2015-11-12 20:12 ` Luke Dashjr
0 siblings, 1 reply; 9+ messages in thread
From: Matt Corallo @ 2015-11-12 19:47 UTC (permalink / raw)
To: bitcoin-dev
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoin-dev] Upcoming Transaction Priority Changes
2015-11-12 19:47 [bitcoin-dev] Upcoming Transaction Priority Changes Matt Corallo
@ 2015-11-12 20:12 ` Luke Dashjr
2015-11-12 20:20 ` Chun Wang
2015-11-12 20:43 ` Jorge Timón
0 siblings, 2 replies; 9+ messages in thread
From: Luke Dashjr @ 2015-11-12 20:12 UTC (permalink / raw)
To: bitcoin-dev, Matt Corallo
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoin-dev] Upcoming Transaction Priority Changes
2015-11-12 20:12 ` Luke Dashjr
@ 2015-11-12 20:20 ` Chun Wang
2015-11-12 20:25 ` Luke Dashjr
2015-11-12 20:43 ` Jorge Timón
1 sibling, 1 reply; 9+ messages in thread
From: Chun Wang @ 2015-11-12 20:20 UTC (permalink / raw)
To: Luke Dashjr; +Cc: bitcoin-dev
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoin-dev] Upcoming Transaction Priority Changes
2015-11-12 20:20 ` Chun Wang
@ 2015-11-12 20:25 ` Luke Dashjr
2015-11-12 20:35 ` James Hilliard
0 siblings, 1 reply; 9+ messages in thread
From: Luke Dashjr @ 2015-11-12 20:25 UTC (permalink / raw)
To: Chun Wang; +Cc: bitcoin-dev
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoin-dev] Upcoming Transaction Priority Changes
2015-11-12 20:25 ` Luke Dashjr
@ 2015-11-12 20:35 ` James Hilliard
0 siblings, 0 replies; 9+ messages in thread
From: James Hilliard @ 2015-11-12 20:35 UTC (permalink / raw)
To: Luke Dashjr; +Cc: bitcoin-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoin-dev] Upcoming Transaction Priority Changes
2015-11-12 20:12 ` Luke Dashjr
2015-11-12 20:20 ` Chun Wang
@ 2015-11-12 20:43 ` Jorge Timón
2015-11-12 21:10 ` Luke Dashjr
1 sibling, 1 reply; 9+ messages in thread
From: Jorge Timón @ 2015-11-12 20:43 UTC (permalink / raw)
To: Luke Dashjr; +Cc: Bitcoin Dev
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).
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoin-dev] Upcoming Transaction Priority Changes
2015-11-12 20:43 ` Jorge Timón
@ 2015-11-12 21:10 ` Luke Dashjr
2015-11-12 21:21 ` Alex Morcos
0 siblings, 1 reply; 9+ messages in thread
From: Luke Dashjr @ 2015-11-12 21:10 UTC (permalink / raw)
To: Jorge Timón; +Cc: Bitcoin Dev
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoin-dev] Upcoming Transaction Priority Changes
2015-11-12 21:10 ` Luke Dashjr
@ 2015-11-12 21:21 ` Alex Morcos
2015-11-12 21:26 ` Luke Dashjr
0 siblings, 1 reply; 9+ messages in thread
From: Alex Morcos @ 2015-11-12 21:21 UTC (permalink / raw)
To: Luke Dashjr; +Cc: Bitcoin Dev
[-- 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 --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoin-dev] Upcoming Transaction Priority Changes
2015-11-12 21:21 ` Alex Morcos
@ 2015-11-12 21:26 ` Luke Dashjr
0 siblings, 0 replies; 9+ messages in thread
From: Luke Dashjr @ 2015-11-12 21:26 UTC (permalink / raw)
To: Alex Morcos; +Cc: Bitcoin Dev
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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2015-11-12 21:27 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-11-12 19:47 [bitcoin-dev] Upcoming Transaction Priority Changes Matt Corallo
2015-11-12 20:12 ` Luke Dashjr
2015-11-12 20:20 ` Chun Wang
2015-11-12 20:25 ` Luke Dashjr
2015-11-12 20:35 ` James Hilliard
2015-11-12 20:43 ` Jorge Timón
2015-11-12 21:10 ` Luke Dashjr
2015-11-12 21:21 ` Alex Morcos
2015-11-12 21:26 ` Luke Dashjr
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox