Change default block priority size to 0 #7022
Conversation
|
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. |
|
Concept ACK On November 15, 2015 1:10:23 PM PST, Alex Morcos notifications@github.com wrote:
|
|
I suppose I need to go fix up tests now.... I'll wait to see whether we want to merge this. |
|
NACK Do we mix priority and low fee transactions here? Anyone seen sustaining attack of low fee high priority transactions? |
|
Concept ACK/utACK, this matches the development agenda of removing priority in general. |
|
Concept ACK |
|
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. |
|
utACK Also agree w/ the idea of marking it "deprecated" |
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
force-pushed
the
defaultPrioritySize
branch
from
c219fd8
to
50947ef
Compare
|
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. |
|
We do not intend to remove priority in future releases (for mining). |
|
@luke-jr yes. I think everyone but you would very much to prefer to On 11/30/15 22:48, Luke-Jr wrote:
|
|
@TheBlueMatt Then miners would be seriously harming Bitcoin to use future releases. NACK. |
|
utACK |
50947ef Change default block priority size to 0 (Alex Morcos)
|
@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. IRC meeting summaries: |
| @@ -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" ] | |||
There was a problem hiding this comment.
I don't like how this changes the default for master but the unit tests run with different settings by default. See #7177
|
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 |
|
@FinalHash then don't run it on your node? |
|
Marshall, you may be missing some context here. This is a change that has been discussed many times among Core's I'm a bit confused about your statement that "when tx's get stuck we can All this change does is reduce the default size of the amount of block Several people (myself included) would like the concept of sorting by
|
|
This is just a warning shot for when you guys make changes without Additionally, I think its a waste of time to do this. All miners have From: Pieter Wuille notifications@github.com Marshall, you may be missing some context here. This is a change that has been discussed many times among Core's I'm a bit confused about your statement that "when tx's get stuck we can All this change does is reduce the default size of the amount of block Several people (myself included) would like the concept of sorting by
� |
|
I'm very glad to hear you like segregated witness (FWIW, I proposed it),
but this is not the place for making decisions about Bitcoin's consensus
rules.
This pull request is about changing a local policy, which every node can
individually decide. It is not a scaling solution, has nothing to do with
the consensus rules of the network, and is just a default.
Segregated witness is not a magic bullet that suddenly means we don't have
anything else to improve anymore, inside Bitcoin Core or elsewhere.
In particular, this change is needed to get the much-faster CreateNewBlock
RPC that 0.12 is introducing.
|
This is not true... |
|
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. |
|
@jyap808 and that is related how? |
|
@dcousens isn't it related to this change being committed? |
|
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. |
|
@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. |
|
Thanks, I'll stop reading Reddit. |
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)