BIP 36 Custom Services Explained: The Closed Peer-Extension Framework

This guide explains BIP 36 Custom Services in plain English. It covers the problem behind the BIP, why it matters and whether the proposal is part of Bitcoin today.

Why custom services were proposed

Developers wanted to experiment with distributed pools, lightweight-client queries, custom transports and routing without consuming scarce standard service bits or colliding with peer commands. BIP 36 attempted to make that experimentation discoverable while reserving a path for a mature service to become a standard NODE flag.

Version-message extension

The proposal appended a variable service count and service definitions after the existing version fields. Each definition contained a name, a 32-bit service version and optional service-specific data. Duplicate names could justify disconnection. Adding variable material to the handshake increased parser and compatibility responsibilities for every peer implementation.

Service identifier rules

Identifiers were constrained to five through eleven ASCII characters, excluded several separators and were intended to be registered before use. The narrow rules reduced collisions but did not authenticate ownership. A malicious peer could advertise a familiar identifier, so clients still had to negotiate and validate actual behaviour.

Namespaced custom commands

A service could use a 12-byte Bitcoin command prefixed with an underscore, then place a null-padded subcommand and payload inside the message. Unknown services and subcommands were to be ignored. Implementations needed strict length and padding checks so a malformed wrapper could not confuse the base message parser.

Optional service data

The handshake could carry small initialisation data, but services hoping to become standard were advised not to depend on it. Standard service flags had no equivalent payload. Moving capabilities into a separate service handshake kept the announcement small and made future transition less dependent on one experimental encoding.

Proposed standardisation path

The document described parallel custom and NODE announcements during transition, dual wrapped and unwrapped reception, and eventual removal of the wrapper. Such dual-mode periods are operationally delicate because one implementation may send, accept or prioritise a different form. The path was not deployed as a generic framework.

Safe modern experiment

Use an isolated network or a separate authenticated transport for a new experimental service. Define explicit framing, version negotiation, resource bounds and teardown. Fuzz duplicate identifiers, unknown commands, non-null padding and oversized payloads.

Conclusion

BIP 36 recorded an early attempt to make peer-service experimentation orderly, but its generic handshake extension did not become the network standard. Modern extensions need their own maintained specification, defensive framing and isolated interoperability tests.