Update vac/raw/random-discovery.md

Co-authored-by: Hanno Cornelius <68783915+jm-clius@users.noreply.github.com>

vac/raw/consensus-hashgraphlike.md

@@ -73,11 +73,11 @@ message Proposal {
   string payload = 11;               // Proposal description
   uint32 proposal_id = 12;           // Unique identifier of the proposal
   bytes proposal_owner = 13;         // Public key of the creator 
-  repeated Votes = 14;               // Vote list in the proposal
+  repeated Vote votes = 14;              // Vote list in the proposal
   uint32 expected_voters_count = 15; // Maximum number of distinct voters
-  uint32 round = 16;                 // Number of Votes 
+  uint32 round = 16;                 // Number of rounds 
   uint64 timestamp = 17;             // Creation time of proposal
-  uint64 expiration_time = 18;       // The time interval that the proposal is active.  
+  uint64 expiration_timestamp = 18;  // The timestamp at which the proposal becomes outdated  
   bool liveness_criteria_yes = 19;   // Shows how managing the silent peers vote
 }
 
@@ -85,7 +85,7 @@ message Vote {
   uint32 vote_id = 20;            // Unique identifier of the vote
   bytes vote_owner = 21;          // Voter's public key
   uint32 proposal_id = 22;        // Linking votes and proposals
-  int64 timestamp = 23;           // Time when the vote was cast
+  uint64 timestamp = 23;          // Time when the vote was cast
   bool vote = 24;                 // Vote bool value (true/false)
   bytes parent_hash = 25;         // Hash of previous owner's Vote
   bytes received_hash = 26;       // Hash of previous received Vote
@@ -138,7 +138,7 @@ check that the hash of the former vote is equal to the `parent_hash` of the late
   
    5.3. Increase the round by one, namely `P_2.round = P_1.round + 1`.
   
-   5.4. Verify that the proposal has not expired by checking that: `P_2.timestamp - current_time < P_1.expiration_time`.
+   5.4. Verify that the proposal has not expired by checking that: `current_time in [P_timestamp, P_expiration_timestamp]`.
     If this does not hold, other peers ignore the message.
 
 After the peer creates the proposal `P_2` with its vote `V_2`,

vac/raw/random-discovery.md

@@ -0,0 +1,90 @@
+---
+title: random-discovery
+name: Random Discovery
+status: raw
+category: Standards Track
+tags:
+editor: Simon-Pierre Vivier <simvivier@status.im>
+contributors: 
+---
+
+## Abstract
+
+TODO blabla summarizing what's in here
+
+## Motivation
+
+TOOD blabla on why we need this
+
+## Semantic
+
+The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”,
+“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document
+are to be interpreted as described in [2119](https://www.ietf.org/rfc/rfc2119.txt).
+
+Please refer to [libp2p Kademlia DHT specification](https://github.com/libp2p/specs/blob/master/kad-dht/README.md) and [extended peer records specification](TODO) for terminology used in this document.
+
+## Protocol
+
+### Record Propagation
+
+A node that wants to make itself discoverable,
+also known as an _advertiser_,
+MUST encode its discoverable information in an [Extensible Peer Record]().
+The encoded information MUST be sufficient for discoverers to connect to this advertiser.
+It MAY choose to encode some or all of its capabilities (and related information)
+as `services` in the `ExtensiblePeerRecord`.
+This will allow future discoverers to filter discovered records based on desired capabilities.
+
+In order to advertise this record,
+the advertiser SHOULD first retrieve the `k` closest peers to its own peer ID
+in its own [Kademlia routing table](https://github.com/libp2p/specs/blob/e87cb1c32a666c2229d3b9bb8f9ce1d9cfdaa8a9/kad-dht/README.md#kademlia-routing-table).
+This assumes that the routing table has been previously initialised
+and follows the regular [bootstrap process](https://github.com/libp2p/specs/blob/e87cb1c32a666c2229d3b9bb8f9ce1d9cfdaa8a9/kad-dht/README.md#bootstrap-process) as per the libp2p Kad-DHT specification.
+The advertiser SHOULD then perform a [Kad-DHT `PUT_VALUE`](https://github.com/libp2p/specs/blob/e87cb1c32a666c2229d3b9bb8f9ce1d9cfdaa8a9/kad-dht/README.md#value-storage-and-retrieval) to these `k` peers
+to store the `ExtensiblePeerRecord` against its own peer ID.
+This process SHOULD be repeated periodically to maintain the advertised record.
+We RECOMMEND an interval of once every `30` minutes,
+for each discoverable `ExtensiblePeerRecord` the node wants to advertise.
+
+### Record Discovery
+
+A random discovery procedure (`FIND_RANDOM`) consist of the following steps;
+
+1. A random value in the key space MUST be chosen (`R_KEY`).
+
+2. A `GET_VALUE` message MUST be sent to the `k` closest nodes to `R_KEY`.
+
+3. A `FIND_NODE` message MUST be sent to the `k` closest nodes to `R_KEY`.
+
+4. For each peers in `closerPeers` from `FIND_NODE` responses, a `GET_VALUE` message MUST be sent but already seen peers MUST be ignored.
+
+5. Repeat step 3 and 4 with new peers found via `FIND_NODE`.
+`FIND_RANDOM` MAY terminate when the `k` closest peers to `R_KEY` are found.
+The discoverer MAY choose to filter discovered `ExtensiblePeerRecords`
+based on advertised `services`
+to find peers matching a set of desired capabilities. 
+> `GET_VALUE` messages MUST always contain the peer id of the recipiant as the `key`
+and the `record` in the response MUST be verified, invalid records and `closerPeers` MUST be discarded. Valid records MAY be filtered for specific services.
+
+### Attack Vectors
+
+To make the system more resilient extended peer records could be stored randomly in the key space
+but doing so would result in increased bandwidth requirements
+because of the need to first find random nodes to store the records at.
+When used in conjuction with [capability discovery](https://github.com/vacp2p/rfc-index/blob/main/vac/raw/logos-capability-discovery.md),
+eclipse attacks effectiveness are greatly reduced
+because a node can always be discovered via it's advertised services regardless of the random discoverability of it's records.
+For this reason, we decided that this trade-off was worth it.
+
+
+## Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
+
+## References
+- [extended peer records specification](TODO)
+- [libp2p Kademlia DHT specification](https://github.com/libp2p/specs/blob/master/kad-dht/README.md)
+- [RFC002 Signed Envelope](https://github.com/libp2p/specs/blob/7740c076350b6636b868a9e4a411280eea34d335/RFC/0002-signed-envelopes.md)
+- [RFC003 Routing Records](https://github.com/libp2p/specs/blob/7740c076350b6636b868a9e4a411280eea34d335/RFC/0003-routing-records.md)
+- [capability discovery](https://github.com/vacp2p/rfc-index/blob/main/vac/raw/logos-capability-discovery.md)