Pricing protocol should not gate connections from bootnode-mode peers
Maintainers usually reply within 2 days
@acud is already working on this.
Since Jul 22, 2026.
Assessment
This issue has not been assessed yet.
Description
Context
Bee's libp2p layer disconnects peers whose pricing ConnectIn / ConnectOut hook returns an error (pkg/p2p/libp2p/libp2p.go around the notifier paths, with the ErrThresholdTooLow / "protocol not supported" failure modes from pkg/pricing/pricing.go). The pricing init always opens a stream to the remote: if the remote does not advertise /swarm/pricing/1.0.0/pricing, bee tears the connection down immediately after handshake.
This makes pricing a hard prerequisite for any peer that wants to stay connected to a bee node — including bootnodes, which conceptually do not participate in chunk accounting at all (they have no payment state to advertise and no incentive to forward chunks). Independent Rust implementations like vertex have a choice between (a) carrying a pricing stub in every bootnode just to satisfy bee's connect notifier, or (b) being forced to disconnect after handshake.
What we are asking for
Make the pricing protocol optional for connections where at least one side advertises itself as a bootnode (whether via the existing BootnodeMode flag, the node type that already drives hive's peersHandler early return, or any other signal bee already has). Concretely: skip the pricing init step entirely when the local node is bootnode-mode, and tolerate "protocol not supported" from the remote when the remote signals bootnode-mode. That removes the requirement for a downstream impl to carry a pricing stub purely for connection-keepalive.
Why this is the right shape
- Pricing's semantic content is chunk accounting; bootnodes are explicitly outside that subsystem. There is no event a bootnode would generate that pricing needs to observe, and no threshold a bootnode has to announce.
- Bootnodes already short-circuit hive ingestion via
BootnodeMode(pkg/hive/hive.go:283-284). Doing the same for pricing closes a parallel "bootnodes do not participate in this accounting subsystem" hole. - Independent implementations are forced to maintain a stub today purely as a compatibility shim. Removing the requirement upstream makes the cross-impl story cleaner and removes a class of "stub kept the connection alive but contributed nothing to operator visibility" bugs.
Acceptance criteria
- A bee node configured in
BootnodeModedoes not initiate a pricing stream on outbound / inbound connection establishment. - A bee node connecting to a peer that does not advertise
/swarm/pricing/1.0.0/pricingdoes not disconnect on that grounds alone when the remote is signalled as bootnode-mode. - Existing pricing / accounting flows between non-bootnode peers are unchanged.
- Dominant language
- Go
- Stars
- 1.5k
- Forks
- 390
- Avg merge
- 2d 11h
- Merged PRs (30d)
- 23
Getting set up
- Ships a Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from ethersphere/bee
-
Chequebook deployment uses a fixed 175,000 gas limit; it needs about 630,000 under Glamsterdam (live on Sepolia since 2026-10-06)Possibly taken @sbackend123 claimed this 10 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
ethersphere/bee#5650 · 1 assignee ·
Maintainers usually reply within 2 days
-
Add a transaction inbox for outbound chain transactionsPossibly taken @sbackend123 claimed this 4 days ago. Openseen
Difficulty 5/5 Over a week Newbie friendliness 35/100
ethersphere/bee#5660 · 1 assignee ·
Maintainers usually reply within 2 days
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
ethersphere/bee#5659 ·
Maintainers usually reply within 2 days
-
accepted seen
Difficulty 4/5 3-5 days Newbie friendliness 40/100
ethersphere/bee#5648 · 1 comment ·
Maintainers usually reply within 2 days
-
pusher: chunksWorker deadlocks on a deferred chunk that fails IdentityAddress (send on nil op.Err), halting all push-syncPossibly taken @sbackend123 claimed this 12 days ago. Openseen
Difficulty 3/5 1-2 days Newbie friendliness 75/100
ethersphere/bee#5641 · 1 assignee ·
Maintainers usually reply within 2 days
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 1 day
-
ViewData can pair the in-flight proposal with the prepared flag of another proposalPossibly taken @HagarMeir claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
hyperledger/SmartBFT#710 ·
Maintainers usually reply within 1 day
-
agent-butler-finding chore
Difficulty 1/5 Under an hour Newbie friendliness 90/100
jordansmall/spindrift#5575 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
open-telemetry/opentelemetry-go-compile-instrumentation#1512 ·
Maintainers usually reply within 3 days
-
Difficulty 1/5 Under an hour Newbie friendliness 86/100
OpenPrinting/go-mfp#124 ·
Maintainers usually reply within 1 day