Introduce CNodePolicy for putting isolated node policy code and parameters on#5071
Introduce CNodePolicy for putting isolated node policy code and parameters on#5071luke-jr wants to merge 3 commits intobitcoin:masterfrom
Conversation
src/policy.cpp
Outdated
There was a problem hiding this comment.
Just copying it from main.cpp, where the code came from. If you want it changed here, make a convincing argument to change it there first.
There was a problem hiding this comment.
All files need changing, but instead of doing it all at once, we're just changing it as files are updated. Please use just MIT.
There was a problem hiding this comment.
This has been discussed already. I though we had merged a PR changing everything to just MIT already.
That would be simpler than warning people every time they copy the license from an outdated place.
ad1dcdb to
7c9d476
Compare
src/main.cpp
Outdated
There was a problem hiding this comment.
Why bother with fRateLimit/fLimitFree at all here, since the logic boils down to:
fRateLimit = !fLimitFree ? false : false
You could just write:
if (!policy.AcceptMemPoolEntry(pool, state, entry, view, false))
return false;
if (!policy.RateLimitTx(pool, state, entry, view))
return false;Is it the idea that more behaviour will be added here or?
There was a problem hiding this comment.
Not all transactions should be rate limited, for different reasons, some of which are policy (contracts with retailers?), some of which are not (local user manually wants to broadcast a transaction).
There was a problem hiding this comment.
Notice fRateLimit is passed to AcceptMemPoolEntry by reference, and it may (and does in some cases by default) change it.
There was a problem hiding this comment.
Right, the pass by reference was what I was missing. LGTM then.
There was a problem hiding this comment.
I agree this feels confusing. I wonder if it ought to be moved onto CValidationState so any step of the process can set it?
ba69a22 to
752418d
Compare
There was a problem hiding this comment.
Why do we even need an object for policy? isnt it all static?
Maybe best to just do a Params()-style Policy()?
There was a problem hiding this comment.
A params-style global hidden behind a function you mean?
I prefer a class.
There was a problem hiding this comment.
@TheBlueMatt It isn't inherently static. It might be nice to one day have nodes with multiple policies, using different ones based on transaction sources and mempools...
|
Idea ACK. @petertodd should also like this since he was positive about it when I proposed in #4298 |
There was a problem hiding this comment.
I don't think this should be called here. This should be in policy.cpp and the field in Policy is not really required.
There was a problem hiding this comment.
This has to be called here. When CNodePolicy is initialised, Policy() might not have been yet.
…eters on Initially populated with policy-specific code moved from AcceptToMemoryPool.
|
Rebased with requested changes. |
|
Needs rebase. On top of #5521 ? |
|
Here's a rebased version (not on top of #5521): https://github.com/jtimon/bitcoin/commits/nodepolicy_old |
|
Here's a version rebased on top of #5114: https://github.com/jtimon/bitcoin/tree/nodepolicy_dust |
Initially populated with policy-specific code moved from AcceptToMemoryPool.
This should make no actual changes, just refactor code. If any change in behaviour is found, it is a bug in this pull request, please report it even if you think it's a good idea.