BIP31, which introduces a protocol extension for Bitcoin that makes it easier to identify non-responsive or "dead" peer connections.

The problem

When Bitcoin clients (the software that runs on your device to connect to the Bitcoin network) run on platforms that can go to sleep (like laptops or mobiles), their network connections might not work correctly when they wake up. The connection might still exist, but not function properly because of changes in IP address or because the peer it was connected to is no longer available.

The Bitcoin client, particularly the original Satoshi client, was largely single-threaded, meaning it processes tasks one at a time. When under heavy load, such as downloading the entire blockchain, the client might become slow to respond to network messages. There was no simple way to detect when a peer was overloaded.

When downloading large data structures, like the blockchain, it's more efficient to connect to a peer close to you in terms of network distance. However, it was difficult to measure the latency to a remote peer, so clients would just select a random peer to download from.

The solution

BIP31 introduced an extension to the Bitcoin protocol to address these issues, specifically using "ping" and "pong" messages. In network communications, a "ping" is a signal sent to a host that requests a response, and the "pong" is the response back. It's a basic way to check if a host is up and running.

Under BIP31, when the Bitcoin client's protocol version is greater than 60000, the "ping" message must contain a uint64 field called "nonce". A nonce is a random or semi-random number that's only used once, and in this context, it's used to identify each "ping" message uniquely.

When a peer sends a "ping", it sets the nonce to a random value, and the recipient echoes it back in a new "pong" message. This way, the client can send a "ping" and measure the time it takes to receive the corresponding "pong". If two "pings" are sent before the first "pong" is received, they can be differentiated using the nonce.

Backward compatibility

This change is backwards compatible, meaning it works with older versions of the protocol. Clients with protocol versions older than 60000 aren't expected to provide a nonce in the "ping" message and won't be sent a "pong".

In simpler terms, imagine you're playing a game of table tennis. You hit the ball (ping) and wait for your opponent to return it (pong). If they take too long to return, you know they're probably tired (overloaded). Now imagine each time you hit the ball, you assign it a number, and when your opponent returns it, they shout back the same number. If they return a ball with a different number, you know that they are mixing up the order of return, which might be a sign of them being disoriented or not being able to keep up with the game. BIP31 essentially introduces this number system (nonces) to the game of ping-pong in the Bitcoin protocol to help identify peers that might be having issues.