Skip to content

Conversation

jtimon
Copy link
Contributor

@jtimon jtimon commented Jan 23, 2015

This is blocking #6051 and #5595

There's no way to start moving consensus and policy code effectively out of main without creating a first .h file.

UPDATE:
It was initially a tiny first step to sepearate consensus and policy but afer a lot of discussion it ended up being a tiny step towards separating only more consensus.

The motivation for this PR is stop blocking the 2 PRs mentioned in line 1.

OUTDATED (for archive):

While we discuss what the CPolicy interface should be #5595, we can start by just moving constants and globals to consensus.h and policy.o.
This will also open the door to some cleaning up on the includes.
nMaxDatacarrierBytes and MAX_OP_RETURN_RELAY are not moved from script/standard.o to policy.o because policy.o is in server while script/standard.o is in common and wouldn't link.

Please propose any other constant or global variable related to consensus or policy that I may have missed.

New but irrelevant:
Are you still reading?

This PR is so simple that the following comments are equivalent:

  • utACK
  • ACK
  • ACK: I didn't read the code but I fully tested in all ways I could think of and it doesn't seem to break anything.
  • I didn't tested it but I did finally read the code.

@jtimon
Copy link
Contributor Author

jtimon commented Jan 26, 2015

Updated adding MANDATORY_SCRIPT_VERIFY_FLAGS to consensus.h and STANDARD_SCRIPT_VERIFY_FLAGS and STANDARD_NOT_MANDATORY_VERIFY_FLAGS to policy.h

@jtimon
Copy link
Contributor Author

jtimon commented Feb 3, 2015

Needed rebase.

* Failing one of these tests may trigger a DoS ban - see CheckInputs() for
* details.
*/
static const unsigned int MANDATORY_SCRIPT_VERIFY_FLAGS = SCRIPT_VERIFY_P2SH;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sold on this part...MANDATORY_SCRIPT_VERIFY_FLAGS is more about "what we accept now", whereas consensus code is generally "what we accept(ed) at the time the block was generated based on its version"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've been thinking that Consensus could be a factory of an interface taking nHeight as parameter instead of a namespace.
Example:

if (Consensus(nHeight).CheckBlock(block, state))

Otherwise all consensus functions affected by softforks will have to take int nHeight as parameter.
But it's probably too soon for something like that.
I'm not sure what you're proposing though, leaving it on script/standard ?

@jtimon
Copy link
Contributor Author

jtimon commented Feb 15, 2015

Rebased adding LOCKTIME_THRESHOLD to consensus.h

@jtimon
Copy link
Contributor Author

jtimon commented Feb 21, 2015

Moved MANDATORY_SCRIPT_VERIFY_FLAGS to policy as suggested by @TheBlueMatt and @sipa

@jtimon jtimon force-pushed the consensus_policy0 branch from c7f0ece to df861be Compare March 3, 2015 19:31
@jtimon
Copy link
Contributor Author

jtimon commented Mar 3, 2015

Renamed policy.o to policy/policy.o

@jtimon jtimon force-pushed the consensus_policy0 branch from df861be to 71a9bef Compare March 11, 2015 13:26
@jtimon
Copy link
Contributor Author

jtimon commented Mar 11, 2015

Not exactly sure why, but it needed rebase. Ping @laanwj @theuni
This is quite trivial and the best first step for any consensus and policy code movements IMO.

@jtimon jtimon force-pushed the consensus_policy0 branch from 71a9bef to ca6793f Compare March 11, 2015 17:08
@jtimon
Copy link
Contributor Author

jtimon commented Mar 11, 2015

Rebased with @laanwj 's fix that should make travis happy again

@maaku
Copy link
Contributor

maaku commented Mar 12, 2015

utACK. I like the direction this is going towards.

@jtimon jtimon force-pushed the consensus_policy0 branch from ca6793f to d5ab935 Compare March 13, 2015 12:21
@jtimon
Copy link
Contributor Author

jtimon commented Mar 13, 2015

Rebased without @laanwj 's fix after #5883 has been merged

@theuni
Copy link
Member

theuni commented Mar 15, 2015

I really don't like the introduction of globals into policy.h, but I understand that they're a temporary measure.

utACK, with the assumption that the globals will be removed fairly quickly.

@jtimon jtimon force-pushed the consensus_policy0 branch 4 times, most recently from 5737c3d to 386ea01 Compare March 26, 2015 11:55
@jtimon
Copy link
Contributor Author

jtimon commented Mar 26, 2015

Needed rebase.

@jtimon
Copy link
Contributor Author

jtimon commented Apr 1, 2015

Closing in favor of #5669 and #5595. The first commit will be in both, the second commit only on the policy PR.

@jtimon jtimon closed this Apr 1, 2015
@jtimon jtimon reopened this Apr 23, 2015
@jtimon jtimon force-pushed the consensus_policy0 branch from 386ea01 to 660cca3 Compare April 23, 2015 00:29
@jtimon
Copy link
Contributor Author

jtimon commented Apr 23, 2015

Reopened as suggested by @theuni

@jtimon jtimon force-pushed the consensus_policy0 branch 2 times, most recently from ae6329b to 691161d Compare April 23, 2015 00:43
@jtimon jtimon changed the title MOVEONLY: Move constants and globals to consensus.h and policy.o MOVEONLY: Move constants consensus.h Apr 23, 2015
@jtimon
Copy link
Contributor Author

jtimon commented Apr 23, 2015

Updated only with the consensus constants but not the policy constants and globals.
This should be hyper-mergeable.

@theuni
Copy link
Member

theuni commented Apr 23, 2015

ACK. I asked @jtimon to re-open this (and slim it down to what it is now) in an effort to focus some of the current tangled PRs. I'm hoping we can serialize some of this work to get it in faster, so I'll take the blame for blowing up everyone's mailboxes with closed/reworked PRs today :).

@morcos
Copy link
Contributor

morcos commented Apr 23, 2015

I like the idea of going ahead and getting some of this reorganization out of the way if we're going to do it. I reviewed this and did some basic testing and it looks good to me.

@sipa
Copy link
Member

sipa commented Apr 24, 2015

ACK

@laanwj laanwj merged commit 691161d into bitcoin:master Apr 26, 2015
laanwj added a commit that referenced this pull request Apr 26, 2015
691161d Consensus: Create consensus/consensus.h with some constants (jtimon)
#include "main.h"
#include "script/script.h"
#include "timedata.h"
#include "ui_interface.h"
#include "util.h"
#include "wallet/db.h"
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why was this needed, seems I can compile without it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The question is not whether you can compile with it or not, the question is whether qt/transactiondesc.cpp is using anything declared in wallet/db.h or not. It's better to indicate dependencies explicitly.

Try commenting #include "main.h" and #include "wallet/db.h" and build again.

You will notice that

#include "coins.h"
#include <boost/foreach.hpp>

is missing but...yeah, you're right. wallet/db.h doesn't seem to be needed anymore.
None of nWalletDBUpdated, CDBEnv, bitdb and CDB is used here.
I am very sorry for putting it there unnecessarily. It seems that you removed it and I added it back in a rebase by accident.
Mhmm, I'll review #6068 in case something similar has happened there.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants