Page MenuHomePhabricator

[avalanche] Limit the conflicting proof rate
ClosedPublic

Authored by Fabien on Dec 21 2021, 12:38.

Details

Reviewers
tyler-smith
Group Reviewers
Restricted Project
Maniphest Tasks
Restricted Maniphest Task
Commits
rABC71c317395b97: [avalanche] Limit the conflicting proof rate
Summary

This is a cooldown feature that prevents 2 consecutives conflicting proofs for the same utxo from being added to a pool in under 1 minute. This will make it impossible for an attacker to generate a large number of votes by suppying conflicting proofs in series. The value of 1 minute is chosen so that it is much larger than the expected convergence time for an avalanche vote, but low enough that it won't prevent a legit proof from being voted on.

This cooldown will later be expanded to prevent a proof that has been voted and accepted from being overriden during a larger time (probably 1h). This will prevent an attacker from messing with our peer set by replacing the proof every minute (see above cooldown).

Ref T1854.

Depends on D10773.

Test Plan
ninja all check-all

Diff Detail

Repository
rABC Bitcoin ABC
Branch
avalanche_next_conflict_time
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 17708
Build 35242: Build Diffbuild-clang-tidy · build-debug · lint-circular-dependencies · build-clang · build-diff · build-without-wallet
Build 35241: arc lint + arc unit

Event Timeline

Fabien requested review of this revision.Dec 21 2021, 12:38
Fabien planned changes to this revision.Dec 21 2021, 14:07

Apply the cooldown from the first proof, not waiting for a conflict.
This makes it easier to reason about.

tyler-smith added inline comments.
src/avalanche/peermanager.cpp
227 ↗(On Diff #31745)

Is there a reason to do this immediately after finding a new higher time, potentially N times, instead of doing it only once right after the loop?

src/avalanche/peermanager.cpp
227 ↗(On Diff #31745)

The time is updated for each conflicting peer, as there might be several. Each of the conflicting peer is updated.
The bestPossibleConflictTime check is indeed done once after the loop.

This logic looks good, correctly implemented, and correctly tested.

src/avalanche/peermanager.cpp
227 ↗(On Diff #31745)

Got it, I see my mistake in understanding now.

This revision is now accepted and ready to land.Jan 30 2022, 23:04
This revision was automatically updated to reflect the committed changes.