[RPCSAGA] Network RPCs, what we need ?

[jaoleal]

Network RPCs

Following the introduction of BanMan with subnet/CIDR support #820 and #899, we can now implement setban, listbanned and clearbanned.

I did a small revamp of what we need and what can already be implemented.

---

1. RPCs ready to implement (infrastructure exists)

When #820 and #899 get implemented.

• setban — Wire BanMan.add_ban() / removal to RPC. Params: subnet, command ("add"/"remove"), bantime, absolute.
• listbanned — Iterate BanMan.banned HashMap. Return: address, ban_created, banned_until, ban_duration, time_remaining.
• clearbanned — Clear BanMan.banned map.
• getconnectioncount — Return LocalPeerView map length.
• getaddednodeinfo — Filter peers by ConnectionKind::Manual, return address + connected status.
• getnodeaddresses — Query AddressMan addresses filtered by count/network.
• addpeeraddress — Call AddressMan::push_addresses() via RPC.
• getaddrmaninfo — Derive counts from AddressMan (good_addresses, addresses, peers_by_service).

2. RPCs requiring new infrastructure

RPC	Blocking requirement
getnettotals	Byte-counting wrappers on TCP read/write in peer.rs; per-peer conntime timestamp
getnetworkinfo	Protocol version constant, local address list, per-network reachability flags, relay policy fields
setnetworkactive	Boolean toggle in the node event loop to pause/resume all P2P activity
getrawaddrman	New/tried table separation with bucket/position metadata in AddressMan (significant redesign)
addconnection	Extend ConnectionKind to map Bitcoin Core types (outbound-full-relay, block-relay-only, addr-fetch) and expose via RPC
sendmsgtopeer	Raw message injection path bypassing NodeRequest enum (testing-only)

3. Existing RPCs not compliant with Bitcoin Core API schema

getpeerinfo — Major gaps (7 fields present out of 40)

Present but with issues:

Floresta field	Bitcoin Core field	Issue
services	services + servicesnames	Missing human-readable names array; serialization format may differ
kind	connection_type	Enum vs string. Bitcoin Core: "outbound-full-relay", "block-relay-only", "inbound", "manual", "addr-fetch", "feeler". Floresta: Feeler, Regular, Extra
transport_protocol	transport_protocol_type	Enum vs string ("v1"/"v2")
user_agent	subver	Field name differs
initial_height	startingheight	Field name differs (also deprecated in Core)
state	—	Extra field, not in Bitcoin Core

Missing fields (require new per-peer tracking):

• Bandwidth: bytessent, bytesrecv, bytessent_per_msg, bytesrecv_per_msg
• Timing: lastsend, lastrecv, conntime, last_transaction, last_block
• Ping: pingtime, minping, pingwait
• Sync state: synced_headers, synced_blocks, inflight, presynced_headers
• Protocol: version (number), inbound, network, addr_relay_enabled
• Address: addrbind, addrlocal, addr_processed, addr_rate_limited
• Other: relaytxes, bip152_hb_to, bip152_hb_from, permissions, minfeefilter, session_id, mapped_as, timeoffset

disconnectnode — Parameter mismatch

• address (param 1) is required in Floresta but optional in Bitcoin Core. Users must pass "" to disconnect by nodeid alone.

addnode — Minor difference

• v2transport defaults to false in Floresta vs config-driven default in Bitcoin Core.

---

[jaoleal]

@csgui Can this be added to Q2 ?

[csgui]

@jaoleal Nice wrap-up of the RPC stuff!! Thanks.

But there’s already a tracking-issue (#839) that will hold RPC related work. It seems they overlap in intent. It’s probably better to complement that RPC tracking-issue with the info you describe here, don't you think?

[jaoleal]

For sure, but i need to state these requirements for our network system and I thought that would be better to gather it on a different issue so #839 doesnt become pollute.

Do you think its better to make this more focused on these needs ?

[csgui]

Do you think its better to make this more focused on these needs ?

Yes, lets try to have focused (smaller) issues. Each issue describing a single task, bug or feature is easier for contributors to understand and act on. Specially RPC ones that touches several points.

But there is valuable technical detail here that can be added to #839 as a guidance too.

[jaoleal]

@jaoleal Nice wrap-up of the RPC stuff!! Thanks.

But there’s already a tracking-issue (#839) that will hold RPC related work. It seems they overlap in intent. It’s probably better to complement that RPC tracking-issue with the info you describe here, don't you think?

As stated here, this issue ends up being a duplicated of 839, information present here will be complemented there.