Skip to content

Conversation

naumenkogs
Copy link
Member

@naumenkogs naumenkogs commented Oct 8, 2022

See #28765

First, this PR enables keeping track of per-peer reconciliation sets, containing those transactions which we intend to exchange efficiently. The remaining transactions are announced via flooding, as usual.

Second, this PR enables periodically initiating a reconciliation round via a new p2p message.

Erlay Project Tracking: #28646

@naumenkogs naumenkogs marked this pull request as draft October 8, 2022 07:30
@naumenkogs
Copy link
Member Author

naumenkogs commented Oct 8, 2022

Marking this draft until

  1. Previous PR is merged Follow-up is merged
  2. There is one in-code TODO I have to resolve (it is minor, but it has to be improved)
  3. I add unit and functional tests for these features.

Another task is to sync parent PR with this version. I have a local branch that compiles, but tests of the full Erlay there needs a little care. If you want to see how this PR works in the broader context, the parent should be good enough to get it. Otherwise, I intend to update it soon.

@DrahtBot DrahtBot added the P2P label Oct 8, 2022
@DrahtBot
Copy link
Contributor

DrahtBot commented Oct 8, 2022

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Code Coverage

For detailed information about the code coverage, see the test coverage report.

Reviews

See the guideline for information on the review process.
A summary of reviews will appear here.

Conflicts

Reviewers, this pull request conflicts with the following ones:

  • #28463 (p2p: Increase inbound capacity for block-relay only connections by mzumsande)
  • #21515 (Erlay: bandwidth-efficient transaction relay protocol by naumenkogs)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

Copy link

@ariard ariard left a comment

Choose a reason for hiding this comment

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

Just few comments as a first parse on the post-#23443 commits.

Copy link
Contributor

@aureleoules aureleoules left a comment

Choose a reason for hiding this comment

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

First code-review parse, left some minor comments.

@naumenkogs naumenkogs force-pushed the 2022-10-erlay2 branch 3 times, most recently from 4afeac2 to cacf08d Compare November 4, 2022 13:21
@naumenkogs naumenkogs force-pushed the 2022-10-erlay2 branch 3 times, most recently from b0c1c43 to 913c2cb Compare November 10, 2022 12:14
@naumenkogs naumenkogs mentioned this pull request Oct 13, 2023
17 tasks
@naumenkogs
Copy link
Member Author

Still have to review a couple of comments, especially the fuzzing suggested by @dergoegge

The pre-mutexed version is useful for external calls, while
the regular version will be used internally.
@naumenkogs naumenkogs force-pushed the 2022-10-erlay2 branch 3 times, most recently from b509e9a to 863a334 Compare October 18, 2023 08:09
@naumenkogs
Copy link
Member Author

naumenkogs commented Oct 18, 2023

This PR is good for review. Fuzzing will come in a separate PR.

Copy link

@ariard ariard left a comment

Choose a reason for hiding this comment

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

will review again pr from scratch

const Consensus::Params& consensusParams = m_chainparams.GetConsensus();

const auto current_time{GetTime<std::chrono::microseconds>()};

// We must look into the reconciliation queue early. Since the queue applies to all peers,
Copy link

Choose a reason for hiding this comment

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

note the call to IsPeerNextToReconcileWith is before MaybeDiscourageAndDisconnect. if a peer is misbehaving and candidate for disconnection, maybe we should disconnect first and let the reconciliation slot be used by another peer

Copy link
Member Author

Choose a reason for hiding this comment

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

This would make a difference only once, which is fine for (lower-risk) outbound peers I think.

The problem with latter IsPeerNextToReconcileWith is that the queue won't be queried. Say, a peer finds a way to exploit MaybeDiscourageAndDisconnect (say in combination with something else) — so that it always returns, but never disconnects. In that case the peer will be stuck at the front of the queue forever.

I don't think what i described is currently possible (fDisconnect only can go from false to true), but I'm afraid it might be in the future.

Transactions eligible for reconciliation are added to the
reconciliation sets. For the remaining txs, low-fanout is used.
For a subset of reconciling peers we announce transactions
via low fanout. We need to set lower intervals for that to
achieve lower relay latency.

Note that for privacy reasons the ratio between inbound and outbound
delays matter more than the actual delays.
When we're finalizing negotiation, we should add the peers
for which we will initiate reconciliations to the queue.
Copy link
Member

@maflcko maflcko left a comment

Choose a reason for hiding this comment

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

left a test nit, feel free to ignore

When the time comes for the peer, we send a
reconciliation request with the parameters which
will help the peer to construct a (hopefully) sufficient
reconciliation sketch for us. We will then use that
sketch to find missing transactions.
@naumenkogs
Copy link
Member Author

I decided to split this off into #28765.

@naumenkogs naumenkogs closed this Nov 1, 2023
@sr-gi sr-gi mentioned this pull request Jun 7, 2024
17 tasks
@bitcoin bitcoin locked and limited conversation to collaborators Oct 31, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

10 participants