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

Handle decryption of ACS results failing #36

Merged
merged 8 commits into from
Jan 16, 2019

Conversation

Vagabond
Copy link
Contributor

If the transaction bundle produced by an ACS instance results in a
failure to decrypt, return the empty list as the result of that ACS and
continue to checking if enough ACSes have completed and we can return a
list of transactions to the user.

If the transaction bundle produced by an ACS instance results in a
failure to decrypt, return the empty list as the result of that ACS and
continue to checking if enough ACSes have completed and we can return a
list of transactions to the user.
@Vagabond Vagabond requested review from evanmcc and vihu January 15, 2019 21:23
@Vagabond
Copy link
Contributor Author

I'm going to add a unit test for this, don't merge yet.

@coveralls
Copy link

coveralls commented Jan 15, 2019

Pull Request Test Coverage Report for Build 353

  • 15 of 17 (88.24%) changed or added relevant lines in 1 file are covered.
  • 1 unchanged line in 1 file lost coverage.
  • Overall coverage increased (+1.2%) to 83.843%

Changes Missing Coverage Covered Lines Changed/Added Lines %
src/hbbft.erl 15 17 88.24%
Files with Coverage Reduction New Missed Lines %
src/hbbft_bba.erl 1 83.11%
Totals Coverage Status
Change from base Build 328: 1.2%
Covered Lines: 384
Relevant Lines: 458

💛 - Coveralls

Copy link
Contributor

@evanmcc evanmcc left a comment

Choose a reason for hiding this comment

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

looks good. is the meat of the change that we now count them as failed instead of continuing to anticipate that they might show up somehow?

@Vagabond
Copy link
Contributor Author

Yes, essentially. I think, however, we should wait for 2f+1 shares before we declare it unsalvageable (because we might have gotten 1 invalid share but f invalid shares). I'm pushing a change to address this.

* Require 2f+1 decryption shares before declaring failure
* Filter invalid shares before trying to combine them
@Vagabond Vagabond merged commit a5586cd into master Jan 16, 2019
@Vagabond Vagabond deleted the adt/handle-failed-decryption branch January 16, 2019 18:12
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.

4 participants