This sends a getavaproofs message upon connection of an avalanche outbound peer or manually added peer with avalanche enabled.
Depends on D11533.
Details
Details
- Reviewers
deadalnix - Group Reviewers
Restricted Project - Commits
- rABC77ff7fb70804: [avalanche] Request compact proofs from our avalanche outbound peers
ninja all check-all
Diff Detail
Diff Detail
- Repository
- rABC Bitcoin ABC
- Branch
- avalanche_send_getavaproofs
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 19224 Build 38196: Build Diff build-without-wallet · lint-circular-dependencies · build-debug · build-clang-tidy · build-diff · build-clang Build 38195: arc lint + arc unit
Event Timeline
| src/net_processing.cpp | ||
|---|---|---|
| 1676 ↗ | (On Diff #33762) | I don't see anything in the condition that would lead me to think this peer is trusted. |
| src/net_processing.cpp | ||
|---|---|---|
| 3699 ↗ | (On Diff #33765) | I don't understand how this is thread safe. |
Comment Actions
I'm not app at all with ho this is going.
I told you what the question was. This is half the work. Either this was thread safe and making things atomic is useless, or it wasn't and then, what about the other fields hat aren't guarded b a mutex? Why didn't thread sanitizer detect it?
Do we really need to wait month or untill something break before making sure that the design make sense?
Comment Actions
I answered the question in D11545 but updated this diff, this is confusing.
There is no race on this because it's always accessed from the same thread. Core tends to put lock requirements on these variables even when not required btw, because they are likely to be used from other threads at some point (see relevant discussion).
For consistency I did the same here, but used an atomic rather than a lock which is enough for the purpose of this variable. The surrounding variable is thead safe but it's not obvious, so I clarified in D11556.