Change default block priority size to 0 #7022

Merged
merged 1 commit into from Dec 1, 2015

Conversation

Projects
None yet
@morcos
Member

morcos commented Nov 15, 2015

As discussed on the mailing list, the current notion of priority is no longer completely supported with the 0.12 release. (In particular limited mempools will not allow free transactions when they have recently hit their limit). It is likely that further support will be removed in future release and the current concept is now deprecated. As such it makes sense to make the mining default not include priority space. It is still supported to create a priority space if the command line argument is changed. (To what degree depends on other open PR's)

@luke-jr

This comment has been minimized.

Show comment
Hide comment
@luke-jr

luke-jr Nov 15, 2015

Member

NACK changing policy defaults as an attempt to influence miners. Also this change would likely be detrimental to Bitcoin in practice, since the priority space is mostly immune to spam attacks.

Member

luke-jr commented Nov 15, 2015

NACK changing policy defaults as an attempt to influence miners. Also this change would likely be detrimental to Bitcoin in practice, since the priority space is mostly immune to spam attacks.

@TheBlueMatt

This comment has been minimized.

Show comment
Hide comment
@TheBlueMatt

TheBlueMatt Nov 15, 2015

Contributor

Concept ACK

On November 15, 2015 1:10:23 PM PST, Alex Morcos notifications@github.com wrote:

As discussed on the mailing
list
,
the current notion of priority is no longer completely supported with
the 0.12 release. (In particular limited mempools will not allow free
transactions when they have recently hit their limit). It is likely
that further support will be removed in future release and the current
concept is now deprecated. As such it makes sense to make the mining
default not include priority space. It is still supported to create a
priority space if the command line argument is changed. (To what
degree depends on other open PR's)
You can view, comment on, or merge this pull request online at:

#7022

-- Commit Summary --

  • Change default block priority size to 0

-- File Changes --

M src/policy/policy.h (2)

-- Patch Links --

https://github.com/bitcoin/bitcoin/pull/7022.patch
https://github.com/bitcoin/bitcoin/pull/7022.diff


Reply to this email directly or view it on GitHub:
#7022

Contributor

TheBlueMatt commented Nov 15, 2015

Concept ACK

On November 15, 2015 1:10:23 PM PST, Alex Morcos notifications@github.com wrote:

As discussed on the mailing
list
,
the current notion of priority is no longer completely supported with
the 0.12 release. (In particular limited mempools will not allow free
transactions when they have recently hit their limit). It is likely
that further support will be removed in future release and the current
concept is now deprecated. As such it makes sense to make the mining
default not include priority space. It is still supported to create a
priority space if the command line argument is changed. (To what
degree depends on other open PR's)
You can view, comment on, or merge this pull request online at:

#7022

-- Commit Summary --

  • Change default block priority size to 0

-- File Changes --

M src/policy/policy.h (2)

-- Patch Links --

https://github.com/bitcoin/bitcoin/pull/7022.patch
https://github.com/bitcoin/bitcoin/pull/7022.diff


Reply to this email directly or view it on GitHub:
#7022

@morcos

This comment has been minimized.

Show comment
Hide comment
@morcos

morcos Nov 15, 2015

Member

I suppose I need to go fix up tests now.... I'll wait to see whether we want to merge this.

Member

morcos commented Nov 15, 2015

I suppose I need to go fix up tests now.... I'll wait to see whether we want to merge this.

@paveljanik

This comment has been minimized.

Show comment
Hide comment
@paveljanik

paveljanik Nov 15, 2015

Contributor

NACK

Do we mix priority and low fee transactions here? Anyone seen sustaining attack of low fee high priority transactions?

Contributor

paveljanik commented Nov 15, 2015

NACK

Do we mix priority and low fee transactions here? Anyone seen sustaining attack of low fee high priority transactions?

@dcousens

This comment has been minimized.

Show comment
Hide comment
@dcousens

dcousens Nov 15, 2015

Contributor

Concept ACK/utACK, this matches the development agenda of removing priority in general.

Contributor

dcousens commented Nov 15, 2015

Concept ACK/utACK, this matches the development agenda of removing priority in general.

@laanwj laanwj added the Mining label Nov 16, 2015

@sdaftuar

This comment has been minimized.

Show comment
Hide comment
@sdaftuar

sdaftuar Nov 16, 2015

Member

Concept ACK

Member

sdaftuar commented Nov 16, 2015

Concept ACK

@TheBlueMatt

This comment has been minimized.

Show comment
Hide comment
@TheBlueMatt

TheBlueMatt Nov 20, 2015

Contributor

Can we also mark the option as "deprecated". Though we may re-add a variation on it in the future, its current version will likely no longer be supported.

Contributor

TheBlueMatt commented Nov 20, 2015

Can we also mark the option as "deprecated". Though we may re-add a variation on it in the future, its current version will likely no longer be supported.

@petertodd

This comment has been minimized.

Show comment
Hide comment
@petertodd

petertodd Nov 21, 2015

Contributor

utACK

Also agree w/ the idea of marking it "deprecated"

Contributor

petertodd commented Nov 21, 2015

utACK

Also agree w/ the idea of marking it "deprecated"

Change default block priority size to 0
Make RPC tests have a default block priority size of 50000 (the old default) so we can still use free transactions in RPC tests.  When priority is eliminated, we will have to make a different change if we want to continue allowing free txs.
@morcos

This comment has been minimized.

Show comment
Hide comment
@morcos

morcos Nov 30, 2015

Member

Updated to make the RPC tests still work by passing in the old -blockprioritysize

To be clear this just changes the default for mining code so that we are properly signaling the intention to remove the current concept of priority in future releases.

Member

morcos commented Nov 30, 2015

Updated to make the RPC tests still work by passing in the old -blockprioritysize

To be clear this just changes the default for mining code so that we are properly signaling the intention to remove the current concept of priority in future releases.

@luke-jr

This comment has been minimized.

Show comment
Hide comment
@luke-jr

luke-jr Nov 30, 2015

Member

We do not intend to remove priority in future releases (for mining).

Member

luke-jr commented Nov 30, 2015

We do not intend to remove priority in future releases (for mining).

@TheBlueMatt

This comment has been minimized.

Show comment
Hide comment
@TheBlueMatt

TheBlueMatt Dec 1, 2015

Contributor

@luke-jr yes. I think everyone but you would very much to prefer to
remove priority as it is used today. There is a bunch of discussion
about adding a similar feature that, instead, effects transactions by
modifying their "effective feerate" in its place, but block priority
space will not be in future releases.

On 11/30/15 22:48, Luke-Jr wrote:

We do not intend to remove priority in future releases (for mining).


Reply to this email directly or view it on GitHub
#7022 (comment).

Contributor

TheBlueMatt commented Dec 1, 2015

@luke-jr yes. I think everyone but you would very much to prefer to
remove priority as it is used today. There is a bunch of discussion
about adding a similar feature that, instead, effects transactions by
modifying their "effective feerate" in its place, but block priority
space will not be in future releases.

On 11/30/15 22:48, Luke-Jr wrote:

We do not intend to remove priority in future releases (for mining).


Reply to this email directly or view it on GitHub
#7022 (comment).

@luke-jr

This comment has been minimized.

Show comment
Hide comment
@luke-jr

luke-jr Dec 1, 2015

Member

@TheBlueMatt Then miners would be seriously harming Bitcoin to use future releases. NACK.

Member

luke-jr commented Dec 1, 2015

@TheBlueMatt Then miners would be seriously harming Bitcoin to use future releases. NACK.

@TheBlueMatt

This comment has been minimized.

Show comment
Hide comment
@TheBlueMatt

TheBlueMatt Dec 1, 2015

Contributor

utACK

Contributor

TheBlueMatt commented Dec 1, 2015

utACK

@laanwj laanwj merged commit 50947ef into bitcoin:master Dec 1, 2015

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

laanwj added a commit that referenced this pull request Dec 1, 2015

Merge pull request #7022
50947ef Change default block priority size to 0 (Alex Morcos)
@dcousens

This comment has been minimized.

Show comment
Hide comment
@dcousens

dcousens Dec 2, 2015

Contributor

@luke-jr from what I can read from the last few IRC meetings, there was a some agreement [yourself excluded] that this would go ahead for 0.12.
Obviously evident from the merge, that seems to be the consensus reached on this?

IRC meeting summaries:
https://forum.bitcoin.com/bitcoin-discussion/bitcoin-dev-irc-meeting-in-layman-s-terms-2015-11-19-t2943.html
https://forum.bitcoin.com/bitcoin-discussion/bitcoin-dev-irc-meeting-in-layman-s-terms-2015-11-12-t2682.html
https://forum.bitcoin.com/bitcoin-discussion/bitcoin-dev-irc-meeting-in-layman-s-terms-2015-11-05-t2285.html

Contributor

dcousens commented Dec 2, 2015

@luke-jr from what I can read from the last few IRC meetings, there was a some agreement [yourself excluded] that this would go ahead for 0.12.
Obviously evident from the merge, that seems to be the consensus reached on this?

IRC meeting summaries:
https://forum.bitcoin.com/bitcoin-discussion/bitcoin-dev-irc-meeting-in-layman-s-terms-2015-11-19-t2943.html
https://forum.bitcoin.com/bitcoin-discussion/bitcoin-dev-irc-meeting-in-layman-s-terms-2015-11-12-t2682.html
https://forum.bitcoin.com/bitcoin-discussion/bitcoin-dev-irc-meeting-in-layman-s-terms-2015-11-05-t2285.html

@@ -217,7 +217,8 @@ def start_node(i, dirname, extra_args=None, rpchost=None, timewait=None, binary=
datadir = os.path.join(dirname, "node"+str(i))
if binary is None:
binary = os.getenv("BITCOIND", "bitcoind")
- args = [ binary, "-datadir="+datadir, "-keypool=1", "-discover=0", "-rest" ]
+ # RPC tests still depend on free transactions
+ args = [ binary, "-datadir="+datadir, "-keypool=1", "-discover=0", "-rest", "-blockprioritysize=50000" ]

This comment has been minimized.

@MarcoFalke

MarcoFalke Dec 9, 2015

Member

I don't like how this changes the default for master but the unit tests run with different settings by default. See #7177

@MarcoFalke

MarcoFalke Dec 9, 2015

Member

I don't like how this changes the default for master but the unit tests run with different settings by default. See #7177

@FinalHash

This comment has been minimized.

Show comment
Hide comment
@FinalHash

FinalHash Dec 14, 2015

As one of the worlds biggest miners I, and i think i speak for all my colleagues when i say, WE DO NOT SUPPORT THIS CHANGE. yes we really dont use it much but when tx's get stuck we can make it work. This is horseshit. Some dude just trying to get a commit based on a conversation. Revert it

As one of the worlds biggest miners I, and i think i speak for all my colleagues when i say, WE DO NOT SUPPORT THIS CHANGE. yes we really dont use it much but when tx's get stuck we can make it work. This is horseshit. Some dude just trying to get a commit based on a conversation. Revert it

@dcousens

This comment has been minimized.

Show comment
Hide comment
@dcousens

dcousens Dec 14, 2015

Contributor

@FinalHash then don't run it on your node?

Contributor

dcousens commented Dec 14, 2015

@FinalHash then don't run it on your node?

@sipa

This comment has been minimized.

Show comment
Hide comment
@sipa

sipa Dec 14, 2015

Member

Marshall, you may be missing some context here.

This is a change that has been discussed many times among Core's
developers, and many (but not all) have wanted to make for a long time.

I'm a bit confused about your statement that "when tx's get stuck we can
make it work". Are you sure you're not talking about the
prioritizetransaction RPC? That keeps working and will continue to do so,
and allows manually bumping a transaction ahead of the queue for mining
purposes.

All this change does is reduce the default size of the amount of block
space dedicated to transactions that get included based on
bitcoindays-destroyed-per-byte (instead of fee per byte) to zero. If there
are problems that can be solved by having such a space, you can always turn
it back on by setting a non-zero size manually.

Several people (myself included) would like the concept of sorting by
bitcoindays-destroyed-per-byte go away entirely over time, however, and
this is a step in that direction.

  • Maintaining this "priority area" complicates the mining-, mempool-,
    wallet-, and fee-estimation code significantly.
  • It works in a very non-optimal way. With a priority space, you may well
    kick out high fee transactions in favor of 0-fee transactions that just
    spend slightly older outputs. If bitcoin-days-destroyed-per-byte is
    something we value, I think we should account for it by having a single
    sort order that combines both, rather than having a dedicated space inside
    blocks.
  • At 50 kB it is hardly a useful measure against spam attacks. If it is, it
    would mean that 950 kB of data is hardly usable due to being filled with
    high-fee spam, and we get a 50 kB "usable" space in every block in which
    actual transactions can occur. The priority space can be set to be bigger
    (and still can be after this PR!), but at that point risks reducing fee
    income significantly. That may not be a worry now at the current fee
    levels, but it's not a solution we should encourage long term, as it is
    incompatible with Bitcoin's long term security (with fees paying for
    security).
  • Bitcoindays-destroyed-per-byte sorting unnecessarily benefits people who
    hold large amounts of old BTC.
Member

sipa commented Dec 14, 2015

Marshall, you may be missing some context here.

This is a change that has been discussed many times among Core's
developers, and many (but not all) have wanted to make for a long time.

I'm a bit confused about your statement that "when tx's get stuck we can
make it work". Are you sure you're not talking about the
prioritizetransaction RPC? That keeps working and will continue to do so,
and allows manually bumping a transaction ahead of the queue for mining
purposes.

All this change does is reduce the default size of the amount of block
space dedicated to transactions that get included based on
bitcoindays-destroyed-per-byte (instead of fee per byte) to zero. If there
are problems that can be solved by having such a space, you can always turn
it back on by setting a non-zero size manually.

Several people (myself included) would like the concept of sorting by
bitcoindays-destroyed-per-byte go away entirely over time, however, and
this is a step in that direction.

  • Maintaining this "priority area" complicates the mining-, mempool-,
    wallet-, and fee-estimation code significantly.
  • It works in a very non-optimal way. With a priority space, you may well
    kick out high fee transactions in favor of 0-fee transactions that just
    spend slightly older outputs. If bitcoin-days-destroyed-per-byte is
    something we value, I think we should account for it by having a single
    sort order that combines both, rather than having a dedicated space inside
    blocks.
  • At 50 kB it is hardly a useful measure against spam attacks. If it is, it
    would mean that 950 kB of data is hardly usable due to being filled with
    high-fee spam, and we get a 50 kB "usable" space in every block in which
    actual transactions can occur. The priority space can be set to be bigger
    (and still can be after this PR!), but at that point risks reducing fee
    income significantly. That may not be a worry now at the current fee
    levels, but it's not a solution we should encourage long term, as it is
    incompatible with Bitcoin's long term security (with fees paying for
    security).
  • Bitcoindays-destroyed-per-byte sorting unnecessarily benefits people who
    hold large amounts of old BTC.
@FinalHash

This comment has been minimized.

Show comment
Hide comment
@FinalHash

FinalHash Dec 14, 2015

This is just a warning shot for when you guys make changes without
discussing it with any miners.

Additionally, I think its a waste of time to do this. All miners have
effectively unanimously agreed two days ago to go with seg wit. I¹ve only
had a small amount of kick back from one dev in particular and the extent of
the warning was, ³Some security issues.² Can you email me and lets get seg
wit going.

From: Pieter Wuille notifications@github.com
Reply-To: bitcoin/bitcoin
<reply+00699eb269f54a2d00441fe9882e973444a98fb312160a3c92cf000000011286680d9
2a169ce06f98dc2@reply.github.com>
Date: Monday, December 14, 2015 at 6:20 AM
To: bitcoin/bitcoin bitcoin@noreply.github.com
Cc: Marshall Long marshall.long@me.com
Subject: Re: [bitcoin] Change default block priority size to 0 (#7022)

Marshall, you may be missing some context here.

This is a change that has been discussed many times among Core's
developers, and many (but not all) have wanted to make for a long time.

I'm a bit confused about your statement that "when tx's get stuck we can
make it work". Are you sure you're not talking about the
prioritizetransaction RPC? That keeps working and will continue to do so,
and allows manually bumping a transaction ahead of the queue for mining
purposes.

All this change does is reduce the default size of the amount of block
space dedicated to transactions that get included based on
bitcoindays-destroyed-per-byte (instead of fee per byte) to zero. If there
are problems that can be solved by having such a space, you can always turn
it back on by setting a non-zero size manually.

Several people (myself included) would like the concept of sorting by
bitcoindays-destroyed-per-byte go away entirely over time, however, and
this is a step in that direction.

  • Maintaining this "priority area" complicates the mining-, mempool-,
    wallet-, and fee-estimation code significantly.
  • It works in a very non-optimal way. With a priority space, you may well
    kick out high fee transactions in favor of 0-fee transactions that just
    spend slightly older outputs. If bitcoin-days-destroyed-per-byte is
    something we value, I think we should account for it by having a single
    sort order that combines both, rather than having a dedicated space inside
    blocks.
  • At 50 kB it is hardly a useful measure against spam attacks. If it is, it
    would mean that 950 kB of data is hardly usable due to being filled with
    high-fee spam, and we get a 50 kB "usable" space in every block in which
    actual transactions can occur. The priority space can be set to be bigger
    (and still can be after this PR!), but at that point risks reducing fee
    income significantly. That may not be a worry now at the current fee
    levels, but it's not a solution we should encourage long term, as it is
    incompatible with Bitcoin's long term security (with fees paying for
    security).
  • Bitcoindays-destroyed-per-byte sorting unnecessarily benefits people who
    hold large amounts of old BTC.


Reply to this email directly or view it on GitHub
#7022 (comment) .

This is just a warning shot for when you guys make changes without
discussing it with any miners.

Additionally, I think its a waste of time to do this. All miners have
effectively unanimously agreed two days ago to go with seg wit. I¹ve only
had a small amount of kick back from one dev in particular and the extent of
the warning was, ³Some security issues.² Can you email me and lets get seg
wit going.

From: Pieter Wuille notifications@github.com
Reply-To: bitcoin/bitcoin
<reply+00699eb269f54a2d00441fe9882e973444a98fb312160a3c92cf000000011286680d9
2a169ce06f98dc2@reply.github.com>
Date: Monday, December 14, 2015 at 6:20 AM
To: bitcoin/bitcoin bitcoin@noreply.github.com
Cc: Marshall Long marshall.long@me.com
Subject: Re: [bitcoin] Change default block priority size to 0 (#7022)

Marshall, you may be missing some context here.

This is a change that has been discussed many times among Core's
developers, and many (but not all) have wanted to make for a long time.

I'm a bit confused about your statement that "when tx's get stuck we can
make it work". Are you sure you're not talking about the
prioritizetransaction RPC? That keeps working and will continue to do so,
and allows manually bumping a transaction ahead of the queue for mining
purposes.

All this change does is reduce the default size of the amount of block
space dedicated to transactions that get included based on
bitcoindays-destroyed-per-byte (instead of fee per byte) to zero. If there
are problems that can be solved by having such a space, you can always turn
it back on by setting a non-zero size manually.

Several people (myself included) would like the concept of sorting by
bitcoindays-destroyed-per-byte go away entirely over time, however, and
this is a step in that direction.

  • Maintaining this "priority area" complicates the mining-, mempool-,
    wallet-, and fee-estimation code significantly.
  • It works in a very non-optimal way. With a priority space, you may well
    kick out high fee transactions in favor of 0-fee transactions that just
    spend slightly older outputs. If bitcoin-days-destroyed-per-byte is
    something we value, I think we should account for it by having a single
    sort order that combines both, rather than having a dedicated space inside
    blocks.
  • At 50 kB it is hardly a useful measure against spam attacks. If it is, it
    would mean that 950 kB of data is hardly usable due to being filled with
    high-fee spam, and we get a 50 kB "usable" space in every block in which
    actual transactions can occur. The priority space can be set to be bigger
    (and still can be after this PR!), but at that point risks reducing fee
    income significantly. That may not be a worry now at the current fee
    levels, but it's not a solution we should encourage long term, as it is
    incompatible with Bitcoin's long term security (with fees paying for
    security).
  • Bitcoindays-destroyed-per-byte sorting unnecessarily benefits people who
    hold large amounts of old BTC.


Reply to this email directly or view it on GitHub
#7022 (comment) .

@sipa

This comment has been minimized.

Show comment
Hide comment
@sipa

sipa Dec 14, 2015

Member
Member

sipa commented Dec 14, 2015

@luke-jr

This comment has been minimized.

Show comment
Hide comment
@luke-jr

luke-jr Dec 14, 2015

Member

In particular, this change is needed to get the much-faster CreateNewBlock RPC that 0.12 is introducing.

This is not true...

Member

luke-jr commented Dec 14, 2015

In particular, this change is needed to get the much-faster CreateNewBlock RPC that 0.12 is introducing.

This is not true...

@jyap808

This comment has been minimized.

Show comment
Hide comment
@jyap808

jyap808 Dec 14, 2015

Contributor

NACK. I have experienced to 2 very normal transactions take a very long time to confirm in the past few days. One took over 13 hours, another took over 24 hours.

Contributor

jyap808 commented Dec 14, 2015

NACK. I have experienced to 2 very normal transactions take a very long time to confirm in the past few days. One took over 13 hours, another took over 24 hours.

@dcousens

This comment has been minimized.

Show comment
Hide comment
@dcousens

dcousens Dec 14, 2015

Contributor

@jyap808 and that is related how?

Contributor

dcousens commented Dec 14, 2015

@jyap808 and that is related how?

@jyap808

This comment has been minimized.

Show comment
Hide comment
@jyap808

jyap808 Dec 15, 2015

Contributor

@dcousens isn't it related to this change being committed?

Contributor

jyap808 commented Dec 15, 2015

@dcousens isn't it related to this change being committed?

@gmaxwell

This comment has been minimized.

Show comment
Hide comment
@gmaxwell

gmaxwell Dec 15, 2015

Member

no, jyap808, the things here are in software that won't be released for months. And, I expect, will go along with other changes that haven't been written yet.

Member

gmaxwell commented Dec 15, 2015

no, jyap808, the things here are in software that won't be released for months. And, I expect, will go along with other changes that haven't been written yet.

@sipa

This comment has been minimized.

Show comment
Hide comment
@sipa

sipa Dec 15, 2015

Member

@jyap808 This is about a change that is merged, but is not in any release, nor anywhere deployed in production yet. If your transaction in the current environment take a long time to confirm, it's certainly not due to this change, and they're likely both too low in fee and too low in priority.

Member

sipa commented Dec 15, 2015

@jyap808 This is about a change that is merged, but is not in any release, nor anywhere deployed in production yet. If your transaction in the current environment take a long time to confirm, it's certainly not due to this change, and they're likely both too low in fee and too low in priority.

@jyap808

This comment has been minimized.

Show comment
Hide comment
@jyap808

jyap808 Dec 15, 2015

Contributor

Thanks, I'll stop reading Reddit.

Contributor

jyap808 commented Dec 15, 2015

Thanks, I'll stop reading Reddit.

@jtoomim jtoomim referenced this pull request in bitcoinclassic/bitcoinclassic Jan 20, 2016

Closed

Revert "Change default block priority size to 0" #22

@hackrush01 hackrush01 referenced this pull request in lbryio/lbryum Feb 9, 2018

Closed

Use different algo for Choosing Coins #221

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment