Raymond Chu
Raymond Chu
This is a valid but known issue that we already have a pending fix for - https://github.com/AleoHQ/snarkOS/pull/3135. We just have not gotten around to cleaning it up, burn-in testing the...
We are burn-in testing the change now, but would still value a review from you @ghostant-1017! Would be helpful to see if your attack is still relevant after this fix.
Please see if the issues are still reproducible with the new changes in #3079.
This PR should address the issue - https://github.com/AleoHQ/snarkOS/pull/3232. The finding was related to another issue we were observing in devnet, but this change should address both concerns. @ghostant-1017 Please confirm...
@ghostant-1017 Happy to re-evaluate the report security, lets correspond in HackerOne regarding that. In the meantime, we have another addition to this fix in the form of https://github.com/AleoHQ/snarkOS/pull/3233 that addresses...
Closing with https://github.com/AleoHQ/snarkOS/pull/3232
@ljedrz Has this issue been resolved?
Though I only have a small snippet of your logs, I believe this should be normal. A prover solution's target is randomly sampled with `u64::MAX / hash_to_u64(commitment)`. With a proof...
Note: This PR was tested on a network with a malicious validator that was spoofing rounds and did not run into block production issues.
You'd want to also store the signatures that you've received for that proposal, because peers won't resign a proposal they've already seen. So just storing a proposal before it is...