Turns off staking in cfund-proposal-state-accept.py and other cfund tests

[marcus290]

Currently cfund-proposal-state-accept fails in the last assert statement here:

# Wait for the proposal to expire
while int(time.time()) <= int(self.nodes[0].getproposal(proposalid0)["expiresOn"]):
    time.sleep(1)

blocks=slow_gen(self.nodes[0], 1)

assert(self.nodes[0].getproposal(proposalid0)["status"] == "expired waiting for end of voting period")

self.nodes[0].invalidateblock(blocks[-1])
assert(self.nodes[0].getproposal(proposalid0)["status"] == "accepted")

The code loops in 1s increments while checking for a proposal's deadline before generating 1 block and asserting the status. I think an additional block may sometimes be generated between the deadline and assert, so there are actually two blocks generated with status: "expired waiting for end of voting period" hence invalidating only one block will fail assert(self.nodes[0].getproposal(proposalid0)["status"] == "accepted") sometimes.

This PR:

• turns off staking consistently in all cfund rpc tests
• comments out console print statements for test output readability

Verifying this fix is hard because the test fails only sometimes. I tested locally and the revised test passed 20/20 times. I will look at this issue again if the test fails again.

[marcus290]

Currently this test fails in Travis builds sometimes but not always.

I tried running it locally and the test fails about 2/30 times.

The test fails at line 158, assert(self.nodes[0].getproposal(proposalid0)["status"] == "accepted"), which is testing the status of a proposal which has just expired and changed from status: "accepted" to status: "expired waiting for end of voting period" then the block is invalidated (supposedly reverting the proposal status to accepted).

Checking with print statements, when the test fails, the proposal status is "expired waiting for end of voting period".

I think the issue could be caused by:

• some problem with invalidateblock(); or
• the status was changed >1 block beforehand, so invalidating 1 block is not enough to revert the status

[aguycalled]

have you tried printing getinfo() to check the block height?

[marcus290]

good idea. I will try and rerun the tests

[marcus290]

I re-ran the test 15 times and the block height is inconsistent by about ±1 block when staking is on. Indeed in some cases, there are 2 blocks with status: "expired waiting for end of voting period" before we call invalidateblock().

With staking off, the block height is consistent, which should fix this test failing.