Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Put height into mined commitments and use it instead of the special handling of quorumVvecHash #2501

Merged
merged 3 commits into from Nov 27, 2018

Conversation

codablock
Copy link

See discussion in dashpay/dips#31

@codablock codablock added this to the 13.0 milestone Nov 26, 2018
Copy link

@UdjinM6 UdjinM6 left a comment

Choose a reason for hiding this comment

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

Loog good 👍

Just a few comments/questions.

src/llmq/quorums_commitment.cpp Outdated Show resolved Hide resolved
src/llmq/quorums_commitment.cpp Outdated Show resolved Hide resolved
src/llmq/quorums_commitment.cpp Show resolved Hide resolved
Copy link

@UdjinM6 UdjinM6 left a comment

Choose a reason for hiding this comment

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

👍

utACK

}

return true;
}

bool CFinalCommitment::VerifyNull(int nHeight) const
bool CFinalCommitment::VerifyNull() const
Copy link
Member

Choose a reason for hiding this comment

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

Not relevant for this PR but I'd like a comment on this method normally, overall comments are fairly limited in this new code

Copy link
Author

Choose a reason for hiding this comment

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

I'll create a PR in the next days to include more documentation in general, hope that helps understanding all the new code.

return state.DoS(100, false, REJECT_INVALID, "bad-qc-height");
}

if (!mapBlockIndex.count(qcTx.commitment.quorumHash)) {
Copy link
Member

Choose a reason for hiding this comment

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

I prefer it to be explicit, I think it is easier to read and it conveys the intent better

Suggested change
if (!mapBlockIndex.count(qcTx.commitment.quorumHash)) {
if (mapBlockIndex.count(qcTx.commitment.quorumHash) != 0) {

if (!Params().GetConsensus().llmqs.count((Consensus::LLMQType)qcTx.commitment.llmqType)) {
return state.DoS(100, false, REJECT_INVALID, "bad-qc-type");
}
const auto& params = Params().GetConsensus().llmqs.at((Consensus::LLMQType)qcTx.commitment.llmqType);
Copy link
Member

Choose a reason for hiding this comment

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

might make sense to have Params().GetConsensus().llmqs stored in a variable instead of fetching it twice, but compiler would probably do that optimization already ¯\(ツ)

Copy link
Author

Choose a reason for hiding this comment

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

Well, the first one is checking for existence (which is an important validity check). The second one actually fetches it (by using at to to indicate that existence is a requirement). I'm usually in favor of using .find(), but only if performance is important at that point (e.g. possibly large maps)

Copy link
Member

@PastaPastaPasta PastaPastaPasta left a comment

Choose a reason for hiding this comment

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

Doesn't this lock only need to happen for the Misbehaving? If that is the case, there isn't really a reason to have it above the print.

@@ -90,7 +90,7 @@ void CQuorumBlockProcessor::ProcessMessage(CNode* pfrom, const std::string& strC

auto members = CLLMQUtils::GetAllQuorumMembers(type, qc.quorumHash);

if (!qc.Verify(members)) {
if (!qc.Verify(members, true)) {
LOCK(cs_main);
Copy link
Member

Choose a reason for hiding this comment

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

Doesn't this lock only need to happen for the Misbehaving? If that is the case, there isn't really a reason to have it above the print. (not really relevant tho ¯\(ツ)/¯)

Copy link
Author

Choose a reason for hiding this comment

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

Yeah, you're right. It's only for Misbehaving. I'd like to avoid fixing that for now as I don't want to loose the ACK for this PR if it's not really required...need to finish RC5.

@@ -79,6 +79,7 @@ class CFinalCommitment
return false;
}
if (quorumPublicKey.IsValid() ||
!quorumVvecHash.IsNull() ||
Copy link
Member

Choose a reason for hiding this comment

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

this seems bad... I don't really know enough about it though, so I'll just point it out and wait for you to say it's correct :)

Copy link
Author

Choose a reason for hiding this comment

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

It's correct, but you made me question it for a second ;)
This method returns false if any of the fields is non-null. For the BLS stuff, that means if they are valid. For uint256, it means that it's not null (all-zero).

Copy link
Member

@PastaPastaPasta PastaPastaPasta left a comment

Choose a reason for hiding this comment

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

utACK, only the one trivial suggestion still above

@codablock codablock merged commit 812834d into dashpay:develop Nov 27, 2018
@codablock codablock deleted the pr_dip6_heightincommitment branch November 27, 2018 07:04
CryptoCentric pushed a commit to absolute-community/absolute that referenced this pull request Jun 29, 2020
…andling of quorumVvecHash (dashpay#2501)

* Allow to skip sig verification for CFinalCommitment::Verify

* Add CFinalCommitmentTxPayload and CheckLLMQCommitment and use it

As described in dashpay/dips#31 (see discussion).

* Properly ban nodes for invalid commitments
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.

None yet

3 participants