-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Skip JoinSplit verification before the last checkpoint #1892
Skip JoinSplit verification before the last checkpoint #1892
Conversation
Here's the result of a rescan:
Two observations:
|
Okay,
So we either need to add checkpoint checks in all those locations, or shift JoinSplit verification to e.g. |
I want to pass in a verification context object to |
9bdeea2
to
7972a86
Compare
Force-pushed to replace the old commit with one based on #1919. This PR is now somewhat more verbose, but also much more explicit about what the verification conditions are, which IMHO is a good thing. |
Here's the log output after updating my local copy of the blockchain using this PR and then restarting to cause a rescan of the fetched blocks:
Note that this PR now also only verifies JoinSplit proofs once per block (past the last checkpoint), instead of three times. |
Reviewed! I'm happy with this. Let's wait until the other PR merges, and then rebase this one. I think @bitcartel will likely suggest more comments though so that we don't break some assumptions later. |
As part of review we should rebase on #1904 and perform -reindex test due to issue seen here: #1904 (comment) |
The problem is reproducible:
|
@bitcartel is it #1919 causing this bug? |
#1919 doesn't cause the problem on its own, and this PR doesn't change anything to do with the witness cache. So it must be a race condition, only encountered when reindexing is fast enough. But that doesn't make sense either, because the bug occurs during reindexing (confirmation @bitcartel?) and everything should be occurring in series... |
@str4d Yep, during reindexing. I haven't been able to test if the problem occurs with a rescan. |
Isolate verification to a ProofVerifier context object that allows verification behavior to be tuned by the caller. This is an alternative foundation for #1892, i.e., #1892 will have to be changed if this PR is accepted. I think this is a safer approach because it allows us to isolate verification behavior to a single object. This will come in handy when @arielgabizon finishes the batching code.
7972a86
to
6fb8d0c
Compare
Rebased on master to pick up the final changes from #1919. |
I am confident that this PR is not the cause of the issue (see #1904 (comment)), but I won't merge it yet to let @bitcartel confirm. @bitcartel please merge this once you are satisfied. |
@zkbot tests on merge, so there's no need to rebase anything, just r+ it |
📌 Commit 6fb8d0c has been approved by |
…points, r=ebfull Skip JoinSplit verification before the last checkpoint Part of #1749
@zkbot r- |
When rebasing on master, I see the assertion again:
When not rebasing, and testing this branch as it is, the assertion is not triggered. |
📌 Commit 6fb8d0c has been approved by |
@zkbot r- |
Will have to merge this after the fix, to get Buildbot to trigger a build. |
Release 1.0.4 fast or just release as it is right now, please, do not overdue more! I have impression like you don't even realize how important the fixed Z transactions are for the market, miners and Zcash itself, briefly for Zcash value! zk-SNARK is a masterpiece crown, without it nobody can see who is the real king! |
ACK. Reindexing was fine (this PR rebased on #1933) |
@zkbot r+ |
📌 Commit 6fb8d0c has been approved by |
@zkbot retry |
…points, r=str4d Skip JoinSplit verification before the last checkpoint Part of #1749
☀️ Test successful - zcash |
Part of #1749