Skip to content

Conversation

@instagibbs
Copy link
Contributor

@instagibbs instagibbs commented Oct 1, 2018

Resolves #424

We ensure that peg-in invalid blocks are marked as "bad", and allow the re-checking logic to actually re-check instead of immediately re-evaluating the block.

Take locks and check for existence of keys in mapBlockIndex, when appropriate.

Also actually includes a valid test for it by making sure it takes more than a few seconds to fix itself but doesn't hit test timeout.

@instagibbs
Copy link
Contributor Author

Checked logs to make sure the spam is gone, and logic looks sound:

2018-10-01 15:55:47 ERROR: Lost connection to bitcoind RPC, you will want to restart after fixing this!
2018-10-01 15:55:47 ERROR: Lost connection to bitcoind RPC, you will want to restart after fixing this!
2018-10-01 15:55:47 ERROR: ConnectBlock(): CheckInputs on 7c2f24eb880d100eff3db9fcfa2ddf68e0efa1b1dd6cecebb5a6c0beb6f0acaa failed with bad-pegin-witness (code 68)
2018-10-01 15:55:47 InvalidChainFound: invalid block=00ab4619b6d65df1ae702a6c0661b77b56d3e331dc1b10ab5ffd9d477e3690e2  height=211  log2_work=7.7279205  date=2018-10-01 15:56:14
2018-10-01 15:55:47 InvalidChainFound:  current best=1440b3740e9e1bdd5f42d46ee97e5f8524ab79146ae43ce6759b98cca2d3ac00  height=210  log2_work=7.7210992  date=2018-10-01 15:56:14
2018-10-01 15:55:47 ERROR: ConnectTip(): ConnectBlock 00ab4619b6d65df1ae702a6c0661b77b56d3e331dc1b10ab5ffd9d477e3690e2 failed
2018-10-01 15:55:47 InvalidChainFound: invalid block=00ab4619b6d65df1ae702a6c0661b77b56d3e331dc1b10ab5ffd9d477e3690e2  height=211  log2_work=7.7279205  date=2018-10-01 15:56:14
2018-10-01 15:55:47 InvalidChainFound:  current best=1440b3740e9e1bdd5f42d46ee97e5f8524ab79146ae43ce6759b98cca2d3ac00  height=210  log2_work=7.7210992  date=2018-10-01 15:56:14
2018-10-01 15:55:52 ERROR: Failure connecting to bitcoind RPC: couldn't connect to server: unknown (code -1)
(make sure server is running and you are connecting to the correct RPC port)
2018-10-01 15:56:07 UpdateTip: new best=00ab4619b6d65df1ae702a6c0661b77b56d3e331dc1b10ab5ffd9d477e3690e2 height=211 version=0x30000000 log2_work=7.7279205 tx=222 date='2018-10-01 15:56:14' progress=1.000000 cache=0.0MiB(224tx)

# Don't make a block, race condition when pegin-invalid block
# is awaiting further validation, nodes reject subsequent blocks
# even ones they create
print("Now waiting for node to re-evaluate peg-in witness failed block... should take a few seconds")
Copy link
Contributor

Choose a reason for hiding this comment

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

Now waiting for node to ...

I was expecting that to be followed by a sleep..

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ok? :)

// Check existence and validity of pegin witness
if (tx.wit.vtxinwit.size() <= i || !IsValidPeginWitness(tx.wit.vtxinwit[i].m_pegin_witness, prevout)) {
return state.DoS(0, false, REJECT_PEGIN, "bad-pegin-witness", true);
return state.DoS(0, false, REJECT_PEGIN, "bad-pegin-witness");
Copy link
Contributor

Choose a reason for hiding this comment

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

What exactly does this change behavior-wise?

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 note this in the issue itself but:

  1. Blocks: block is marked bad and not reprocessed until the next retry interval

  2. Transactions: transaction is rejected, like normal.

'-mainchainrpcport=%s' % rpc_port(n),
'-mainchainrpcuser=%s' % rpc_u,
'-mainchainrpcpassword=%s' % rpc_p,
'-recheckpeginblockinterval=15', # Long enough to allow failure and repair before timeout
Copy link
Contributor

Choose a reason for hiding this comment

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

You don't seem to wait for 15 seconds ever, so if you just want to make sure all things happen before the timeout, why not use the default?

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 node takes 15 seconds to re-try the block, so we do use it. I don't want it lost in node start/stop time noise.

@stevenroose
Copy link
Contributor

Tests work though, at 2716fab. But confused about the not waiting in the fedpeg test.

@instagibbs
Copy link
Contributor Author

I'll give the code some documentation to clear up some of these questions.

* 2) Re-evaluates a list of blocks that have been deemed "bad"
* from the perspective of peg-in witness validation. Blocks are
* added to this queue in ConnectTip based on the error code returned.
*/
Copy link
Contributor

Choose a reason for hiding this comment

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

Thank you 💋

Previously the peg-in validation logic was done in script
which means it was handled correctly by mempool/block logic.

We then moved these checks outside of script, which means
that these checks aren't multithreaded/batched, and return
the specific error states, including CorruptionPossible.

This means that blocks are never considered permanently invalid and
in certain circumstances tried in an infinite loop.

Instead we mark it as a normal failure, and allow the peg-in invalid
block queue to take care of it instead.
@instagibbs
Copy link
Contributor Author

rebased, this time with Travis testing the bitcoind case!

@stevenroose
Copy link
Contributor

tACK 4a2ba83

@instagibbs instagibbs merged commit abb7b01 into ElementsProject:elements-0.14.1 Oct 3, 2018
instagibbs added a commit that referenced this pull request Oct 3, 2018
abb7b01 Add some additional comments about BitcoindRPCCheck infra (Gregory Sanders)
62c56f4 don't set CorruptionPossible for peg-in transaction failure (Gregory Sanders)
5d7cd6b parameterize the rpc re-checking of peg-in validation failed blocks (Gregory Sanders)
ba8d498 bitcoind rpc check should take main locks for mapBlockIndex, check for key (Gregory Sanders)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants