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

backport: Merge bitcoin#22423, 22096 #5884

Open
wants to merge 2 commits into
base: develop
Choose a base branch
from

Conversation

vijaydasmp
Copy link

@vijaydasmp vijaydasmp commented Feb 19, 2024

bitcoin backports

@vijaydasmp vijaydasmp changed the title backport: Merge bitcoin#16795 backport: Merge bitcoin#22520, 22423, 22371, 22096 May 7, 2024
@vijaydasmp vijaydasmp force-pushed the bp23_2 branch 7 times, most recently from f71025e to e17634c Compare May 17, 2024 06:24
@vijaydasmp vijaydasmp changed the title backport: Merge bitcoin#22520, 22423, 22371, 22096 backport: Merge bitcoin#22423, 22096 May 17, 2024
fanquake and others added 2 commits May 18, 2024 09:40
…cements

5730a43 test: Add functional test for AddrFetch connections (Martin Zumsande)
c34ad33 net, rpc: Enable AddrFetch connections for functional testing (Martin Zumsande)
533500d p2p: Add timeout for AddrFetch peers (Martin Zumsande)
b6c5d1e p2p: AddrFetch - don't disconnect on self-announcements (Martin Zumsande)

Pull request description:

  AddrFetch connections (old name: oneshots) are intended to be short-lived connections on which we ask a peer for addresses via `getaddr` and disconnect after receiving them.

  This is done by disconnecting after receiving the first `addr`. However, it is no longer working as intended, because nowadays, the first `addr` a typical bitcoin core node sends is its self-announcement.
  So we'll disconnect before the peer gets a chance to answer our `getaddr`.

  I checked that this affects both `-seednode` peers specified manually, and DNS seeds when AddrFetch is used as a fallback if DNS doesn't work for us.

  The current behavior of getting peers via AddrFetch when starting with an empty addrman would be to connect to the peer, receive its self-announcement and add it to addrman, disconnect, reconnect to the same peer again as a full outbound (no other addresses in addrman) and then receive more `addr`. This is silly and not in line with AddrFetch peer being intended to be short-lived peers. 

  Fix this by only disconnecting after receiving an `addr` message of size > 1.

  [Edit] As per review discussion, this PR now also adds a timeout after which we disconnect if we haven't received any suitable `addr`, and a functional test.

ACKs for top commit:
  amitiuttarwar:
    reACK 5730a43
  naumenkogs:
    ACK 5730a43
  jnewbery:
    ACK 5730a43

Tree-SHA512: 8a81234f37e827705138eb254223f7f3b3bf44a06cb02126fc7990b0d231b9bd8f07d38d185cc30d55bf35548a6fdc286b69602498d875b937e7c58332158bf9
…dup, cleanup, logging)

a006d7d test: add logging to wallet_listtransactions (Sebastian Falbesoner)
47915b1 test: remove unneeded/redundant code in wallet_listtransactions (Sebastian Falbesoner)
fb6c6a7 test: speedup wallet_listtransactions by whitelisting peers (immediate tx relay) (Sebastian Falbesoner)

Pull request description:

  This PR improves the test `wallet_listtransactions.py` in three ways:
  * speeds up runtime by a factor of 2-3x by using the good ol' immediate tx relay trick (`-whitelist=noban@127.0.0.1`)
  * removes unneeded/redundant code
  * adds log messages, mostly by turning comments into `self.log.info(...)` calls

ACKs for top commit:
  jonatack:
    ACK a006d7d
  kristapsk:
    ACK a006d7d

Tree-SHA512: a91a19f5ebc4d05f0b96c5419683c4c57ac0ef44b64eeb8dd550bd72296fd3a2857a3ba83f755fe4b0b3bd06439973f226070b5d0ce2dee58344dae78cb50290
@vijaydasmp vijaydasmp marked this pull request as ready for review May 18, 2024 12:00
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.

None yet

2 participants