From 1dd71ebaf8d1f594ac55ffc2dc6076f37d1be300 Mon Sep 17 00:00:00 2001
From: Felix Lange <fjl@twurst.com>
Date: Mon, 26 Mar 2018 19:30:59 +0200
Subject: [PATCH] EIP-868: add sequence number to ping and pong

---
 EIPS/eip-868.md | 61 +++++++++++++++++++++++++++++++++++++------------
 1 file changed, 46 insertions(+), 15 deletions(-)

diff --git a/EIPS/eip-868.md b/EIPS/eip-868.md
index 41732b42..5cfa2b48 100644
--- a/EIPS/eip-868.md
+++ b/EIPS/eip-868.md
@@ -18,35 +18,66 @@ resolution of Ethereum Node Records (ENR).
 
 To bridge current and future discovery networks and to aid the implementation of other
 relay mechanisms for ENR such as DNS, we need a way to request the most up-to-date version
-of a node record.
+of a node record. This EIP provides a way to request it using the existing discovery
+protocol.
 
 # Specification
 
-Implementations of Node Discovery Protocol v4 should support two new packet types, a request
-and reply of the node record. The new packets are:
+Implementations of Node Discovery Protocol v4 should support two new packet types, a
+request and reply of the node record. The existing ping and pong packets are extended with
+a new field containing the sequence number of the ENR.
 
-### enrRequest (0x05)
+### Ping Packet (0x01)
 
-RLP: `[ expiration ]`
+```text
+packet-data = [version, from, to, expiration, enr-seq]
+```
 
-When a packet of this type is received, the node should reply with an enrResponse packet
+`enr-seq` is the current sequence number of the sending node's record. All other fields
+retain their existing meaning.
+
+### Pong Packet (0x02)
+
+```text
+packet-data = [to, ping-hash, expiration, enr-seq]
+```
+
+`enr-seq` is the current sequence number of the sending node's record. All other fields
+retain their existing meaning.
+
+### ENRRequest Packet (0x05)
+
+```text
+packet-data = [ expiration ]
+```
+
+When a packet of this type is received, the node should reply with an ENRResponse packet
 containing the current version of its record.
 
-To guard against amplification attacks, the sender of enrRequest should have replied to a
-ping packet recently. The expiration field, a UNIX timestamp, should be handled as for all
-other existing packets, i.e. no reply should be sent if it refers to a time in the past.
+To guard against amplification attacks, the sender of ENRRequest should have replied to a
+ping packet recently (just like for FindNode). The `expiration` field, a UNIX timestamp,
+should be handled as for all other existing packets i.e. no reply should be sent if it
+refers to a time in the past.
 
-### enrResponse (0x06)
+### ENRResponse Packet (0x06)
 
-RLP: `[ requestHash, ENR ]`
+```text
+packet-data = [ request-hash, ENR ]
+```
 
-This packet is the response to enrRequest.
+This packet is the response to ENRRequest.
 
-- `requestHash` is the hash of the entire enrRequest packet being replied to.
+- `request-hash` is the hash of the entire ENRRequest packet being replied to.
 - `ENR` is the node record.
 
-The recipient of the packet should verify that the node record is signed by node who
-sent enrResponse.
+The recipient of the packet should verify that the node record is signed by node who sent
+ENRResponse.
+
+## Resolving Records
+
+To resolve the current record of a node public key, perform a recursive Kademlia lookup
+using the FindNode, Neighbors packets. When the node is found, send ENRRequest to it and
+return the record from the response.
 
 # Copyright