cap total connections, and document the P2P port 8444
Build docker image and push to registry.bitdeals.org / main-build-job (push) Successful in 2m12s

The daemon has always listened on 8444 and nothing published it, so every
node built from this image was outbound-only. Publishing it is now a
documented choice rather than an omission -- including the two things that
are not obvious from the config: peers are told the port from `port` in
keys.dat rather than the one you mapped it to (so only 8444:8444 works),
and the node's own address is never configured at all, because every peer
replaces the hardcoded 127.0.0.1 in the version message with the IP it
sees on the socket.

An open port needs a brake, hence BITMESSAGE_MAXTOTALCONNECTIONS. It
defaults to the PyBitmessage stock 200, so nothing changes for existing
users of the image. The key is inserted when the stock config lacks it
instead of trusting the substitution: the PyBitmessage clone is unpinned,
and a silent no-op would ship a node that looks capped and is not.

The API port in the example compose moves to loopback, which is what the
README already prescribed.
This commit is contained in:
bitdeals git user
2026-08-02 14:48:01 +00:00
parent 335ee52c0d
commit 2701c57200
5 changed files with 96 additions and 7 deletions
+29 -3
View File
@@ -14,8 +14,11 @@ The container generates a Bitmessage Deterministic Addresses based on a `BITMESS
Here are some example snippets to help you get started creating a container.
The XML-RPC API controls the daemon completely and has no TLS. Set your own
credentials and keep the port on loopback.
The container has two ports and they are not interchangeable. **8442** is the
XML-RPC API: it controls the daemon completely and has no TLS, so set your own
credentials and keep it on loopback. **8444** is the Bitmessage P2P port:
publish it to let other nodes connect in, leave it unpublished to stay
outbound-only. The daemon listens on both inside the container either way.
## docker-compose
@@ -33,8 +36,10 @@ services:
- BITMESSAGE_SEED_ADDRESSES=1
- BITMESSAGE_TTL=172800
- BITMESSAGE_STOPRESENDINGAFTERXDAYS=60
- BITMESSAGE_MAXTOTALCONNECTIONS=40
ports:
- 127.0.0.1:8442:8442
- 127.0.0.1:8442:8442 # API — loopback only
- 8444:8444 # P2P — omit this line to stay outbound-only
volumes:
- bitmessage:/home/bitmessage
@@ -52,7 +57,9 @@ docker run -d \
-e BITMESSAGE_SEED_ADDRESSES=1 \
-e BITMESSAGE_TTL=172800 \
-e BITMESSAGE_STOPRESENDINGAFTERXDAYS=60 \
-e BITMESSAGE_MAXTOTALCONNECTIONS=40 \
-p 127.0.0.1:8442:8442 \
-p 8444:8444 \
-v bitmessage:/home/bitmessage \
registry.bitdeals.org/bitmessage
```
@@ -64,6 +71,7 @@ Container images are configured using parameters passed at runtime.
|Parameter|Function|
|:--------|:-------|
|-p 127.0.0.1:8442|API port. The daemon always binds `0.0.0.0` inside the container, so what you publish decides who reaches it|
|-p 8444|Bitmessage P2P port. Optional: without it the node still connects out to peers, it just cannot be connected to. Must be published as `8444:8444` — see Notes|
|-v /home/bitmessage|Data directory: `keys.dat` (identity, settings) and `messages.dat`. Without it the node is a new node after every update|
|-e BITMESSAGE_API_USER|XML-RPC API user. Default: `bitmessage_api_user` — change it|
|-e BITMESSAGE_API_PASSWORD|XML-RPC API password. Default: `bitmessage_api_password` — change it, see Notes|
@@ -72,6 +80,7 @@ Container images are configured using parameters passed at runtime.
|-e BITMESSAGE_TTL|The expiration of newly send messages, in seconds. Default: `172800`|
|-e BITMESSAGE_STOPRESENDINGAFTERXDAYS|Stop resending unreceived message after X days. Default: `30`|
|-e BITMESSAGE_APIVARIANT|provides xml or json-RPC API. Default: `legacy`|
|-e BITMESSAGE_MAXTOTALCONNECTIONS|Cap on all connections at once, inbound and outbound together (`maxoutboundconnections` is 8, so this minus 8 is the inbound headroom). Default: `200`, the PyBitmessage stock value — lower it when the P2P port is published|
# Notes
@@ -84,3 +93,20 @@ Container images are configured using parameters passed at runtime.
- The container turns healthy once the daemon has a network connection, which
on a new node takes a few minutes. The start period also covers the startup
`VACUUM` of `messages.dat`.
- **The P2P port must be published as `8444:8444`.** The daemon tells peers the
port from its own config (`port` in `keys.dat`), not the port you mapped it
to, so `8555:8444` advertises a port nobody can reach. A different host port
needs `extport` in `keys.dat`, which this container does not template.
- **Your own address is never configured.** The version message carries a
hardcoded `127.0.0.1` that every peer discards in favour of the IP it sees on
the socket, and it takes the port from that same message. So a node with 8444
published is found by the network on its own, as soon as it connects out —
there is no host IP or DNS name to set anywhere. The one exception is a Tor
hidden service, which needs an explicit `onionhostname`.
- **Publishing 8444 is a deliberate security trade-off.** The daemon runs on
Python 2 and already parses untrusted data from its outbound peers, so an open
port does not create that exposure — it changes *who* may connect, *when*, and
*how many*. The pre-handshake parser becomes reachable by anyone, and the
practical risk is resource exhaustion rather than code execution. Keep
`BITMESSAGE_MAXTOTALCONNECTIONS` low and put memory and CPU limits on the
container.