From 724139a1f81526648dd0055d4ab4bdfa34796477 Mon Sep 17 00:00:00 2001 From: Danny Ryan Date: Tue, 19 May 2020 10:23:12 -0600 Subject: [PATCH 1/2] change gossipsub protocol ID to /meshsub/1.1.0 --- specs/phase0/p2p-interface.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specs/phase0/p2p-interface.md b/specs/phase0/p2p-interface.md index 01d905a38..c8893ead9 100644 --- a/specs/phase0/p2p-interface.md +++ b/specs/phase0/p2p-interface.md @@ -178,7 +178,7 @@ Where Clients MUST support the [gossipsub v1](https://github.com/libp2p/specs/tree/master/pubsub/gossipsub) libp2p protocol including the [gossipsub v1.1](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md) extension. -**Protocol ID:** `/meshsub/1.0.0` +**Protocol ID:** `/meshsub/1.1.0` **Gossipsub Parameters** From fdc7e846dfbffe172dd17805550a4980e16e7a36 Mon Sep 17 00:00:00 2001 From: Danny Ryan Date: Tue, 19 May 2020 10:25:43 -0600 Subject: [PATCH 2/2] remove incorrect table format --- specs/phase0/p2p-interface.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/specs/phase0/p2p-interface.md b/specs/phase0/p2p-interface.md index c8893ead9..0e8699555 100644 --- a/specs/phase0/p2p-interface.md +++ b/specs/phase0/p2p-interface.md @@ -218,8 +218,6 @@ where `base64` is the [URL-safe base64 alphabet](https://tools.ietf.org/html/rfc The payload is carried in the `data` field of a gossipsub message, and varies depending on the topic: -| Name | Message Type | -|------------------------------------------------|-------------------------| | Name | Message Type | |----------------------------------|---------------------------| | `beacon_block` | `SignedBeaconBlock` | @@ -552,7 +550,7 @@ Clients MUST order blocks by increasing slot number. Clients MUST respond with blocks from their view of the current fork choice -- that is, blocks from the single chain defined by the current head. Of note, blocks from slots before the finalization MUST lead to the finalized block reported in the `Status` handshake. -Clients MUST respond with blocks that are consistent from a single chain within the context of the request. After the initial block clients MAY stop in the process of responding, if their fork choice changes the view of the chain in the context of the request. +Clients MUST respond with blocks that are consistent from a single chain within the context of the request. After the initial block, clients MAY stop in the process of responding if their fork choice changes the view of the chain in the context of the request. #### BeaconBlocksByRoot