Skip to content

[pull] master from bitcoin:master#1016

Merged
pull[bot] merged 4 commits intomrpeertopeer:masterfrom
bitcoin:master
Mar 2, 2026
Merged

[pull] master from bitcoin:master#1016
pull[bot] merged 4 commits intomrpeertopeer:masterfrom
bitcoin:master

Conversation

@pull
Copy link

@pull pull bot commented Mar 2, 2026

See Commits and Changes for more details.


Created by pull[bot] (v2.0.0-alpha.4)

Can you help keep this open source service alive? 💖 Please sponsor : )

vasild and others added 4 commits February 2, 2026 09:14
If the following two events happen:

* (likely) the automatic 10 initial connections are not made to all
  networks
* (unlikely) the network-specific logic kicks in almost immediately.
  It is using exponential distribution with a mean of 5 minutes
  (`rng.rand_exp_duration(EXTRA_NETWORK_PEER_INTERVAL)`).

So if both happen, then the 11th connection may not be the expected
private broadcast, but a network-specific connection.

Fix this by retrieving the connection type from
`destinations_factory()`. This is more flexible because it allows
connections to happen in any order and does not break if e.g. the 11th
connection is not the expected first private broadcast.

This also makes the test run faster:
before: 19-44 sec
now: 10-25 sec
because for example there is no need to wait for the initial 10
automatic outbound connections to be made in order to proceed.

Fixes: #34387
I2P addresses must use port=0, otherwise `bitcoind` refuses to connect.

The test `p2p_private_broadcast.py` cannot simulate connections to I2P
peers, so the I2P proxy is set to a dummy `127.0.0.1:1`. Still it is
good to pick I2P addresses and attempt connections to increase coverage.

However the test uses port=8333 for I2P addresses and thus the
connection attempts fail for the "wrong" reason:

```
Error connecting to ...i2p:8333, connection refused due to arbitrary port 8333
```

Using the proper port=0 makes the failures:

```
Error connecting to ...i2p:0: Cannot connect to 127.0.0.1:1
```

which will make possible simulated I2P connections once we have a test
I2P proxy.
…e_broadcast.py

da7f70a test: use port 0 for I2P addresses in p2p_private_broadcast.py (Vasil Dimov)
a8ebcfd test: let connections happen in any order in p2p_private_broadcast.py (Vasil Dimov)
67696b2 net: extend log message to include attempted connection type (Vasil Dimov)

Pull request description:

  If the following two events happen:

  * (likely) the automatic 10 initial connections are not made to all
    networks
  * (unlikely) the network-specific logic kicks in almost immediately.
    It is using exponential distribution with a mean of 5 minutes
    (`rng.rand_exp_duration(EXTRA_NETWORK_PEER_INTERVAL)`).

  So if both happen, then the 11th connection may not be the expected
  private broadcast, but a network-specific connection.

  Fix this by retrieving the connection type from
  `destinations_factory()`. This is more flexible because it allows
  connections to happen in any order and does not break if e.g. the 11th
  connection is not the expected first private broadcast.

  This also makes the test run faster:
  before: 19-44 sec
  now: 10-25 sec
  because for example there is no need to wait for the initial 10
  automatic outbound connections to be made in order to proceed.

  Fixes: #34387

ACKs for top commit:
  achow101:
    ACK da7f70a
  andrewtoth:
    ACK da7f70a
  mzumsande:
    Code Review ACK da7f70a

Tree-SHA512: 7c293e59c15c148a438e0119343b05eb278205640658c99336d4caf4848c5bae92b48e15f325fa616cbc9d5f394649abfa02406a76e802cffbd3d312a22a6885
@pull pull bot locked and limited conversation to collaborators Mar 2, 2026
@pull pull bot added the ⤵️ pull label Mar 2, 2026
@pull pull bot merged commit 6b0a980 into mrpeertopeer:master Mar 2, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants