GossipSub: disabling unused From/Seqno/Signature #1981

protolambda · 2020-07-23T15:23:07Z

For initial introduction of options in GossipSub, please have a look at: libp2p/go-libp2p-pubsub#359

The TLDR:

fields in the Message protobuf in gossipsub are optional
some clients use it, some randomize it, some verify it
it's a privacy issue
with enough effort, you can cause a little peer-scoring chaos in the network by crafting bad messages

What now?

Not part of the planned spec release. No immediate breaking changes.
Need to coordinate to disable verification of From/Seqno/Signature/Key (we don't use it, message-ID is content-based, it only uses Data), and accept it if the data is omitted from any message (already optional in protobuf definition)
Proposal: Give it a week or two for every Medalla node to update into no-verification mode, where these fields can be nil
Then later move into strict mode, where messages that use any of the fields are not accepted anymore.
Result: avoid privacy and verification issues of fields that are not used in Eth2.

cc @jrhea @AgeManning @raulk

The text was updated successfully, but these errors were encountered:

protolambda · 2020-07-23T15:41:20Z

In case of the golang implementation, this would look like:

Start using the WithMessageSignaturePolicy(LaxNoSign) option, instead of WithStrictSignatureVerification(false), WithMessageSigning(false)
- From and Seqno will still be put in messages (pubsub.signID is not nil), but Signature is not (message signing is not enabled, like now)
A week or two later, when the network is ready: use WithMessageSignaturePolicy(StrictNoSign), and WithNoAuthor().
- From, Seqno, Signature will all be nil (i.e. optional protobuf field is omitted).
- Messages of clients that did not update, and are still producing Seqno and From, will be dropped.

This can be done without changing consensus itself, but still affects the network enough to take extra care, enough time to update, and iterate on the plan before committing to it. It's just an unused option in golang pubsub for now, after some initial feedback.

Clients can help by:

share their current behavior (quick yes/no answers):
- Is Signature required to be present?
- Is Signature verified, if present?
- Is Seqno required to be present?
- Is From required to be present?
- Do you set the From field?
- Do you randomize/zero the From field?
- Do you set the Seqno field?
- Do you randomize the Seqno field?
- Do you modify From/Seqno data upon propagation?
share your thoughts about updating

Tracking table:

Q	Lighthouse	Prysm	Teku	Nimbus	Lodestar
Is Signature required to be present?	N	N	N	N	N
Is Signature verified, if present?	N	Y	N	N	Y
Is Seqno required to be present?	N	N	N	N	N
Is From required to be present?	N	N	N	N	N
Do you set the From field?	Y	Y	Y	Y	Y
Do you randomize/zero the From field?	N	N	N	N	N
Do you set the Seqno field?	Y	Y	Y	Y	Y
Do you randomize the Seqno field?`*`	Y`**`	N	N	N	Y
Do you modify From/Seqno data upon propagation?	N	N	N	N	N

*: Prysm inits with nano-second time, Jvm inits randomly. They increment by 1 (causes various minor privacy issues). (answered Yes is more like a No in that regard)
**: Lighthouse zeroes From/Seqno when authoring a message

dryajov · 2020-07-23T16:15:36Z

Here's Nimbus (nim-libp2p) current behavior:

Is a signature required to be present? - No
- optional, disabled for eth2
Are signature verified, if present? - No
- optional, disabled for eth2
Is Seqno required to be present? - No
Is From required to be present? - No
Do you set the From field? - Yes
Do you randomize/zero the From field? - No
Do you set the Seqno field? - Yes
Do you randomize the Seqno field? - No
Do you modify From/Seqno data upon propagation? - No

protolambda · 2020-07-23T16:19:04Z

@dryajov, sorry, maybe I should have added more questions. When you say "optional, disabled for eth2" for the signature, does that mean you reject messages with a signature, or just ignore the signature?

dryajov · 2020-07-23T16:27:34Z

It means that we don't require the signature to be present and if it is present we do not verify it for eth2. However, nim-libp2p allows to configure this, so one can enable it if desired.

wemeetagain · 2020-07-23T16:58:19Z

js-libp2p-gossipsub+lodestar behavior:

Is a signature required to be present? - N
Are signature verified, if present? - Y
Is Seqno required to be present? - N
Is From required to be present? - N
Do you set the From field? - Y
Do you randomize/zero the From field? - N
Do you set the Seqno field? - Y
Do you randomize the Seqno field? - Y
Do you modify From/Seqno data upon propagation? - N

Nashatyrev · 2020-07-23T17:56:17Z

Teku:

Is a signature required to be present? - N
Are signature verified, if present? - N
Is Seqno required to be present? - Y
Is From required to be present? - N
Do you set the From field? - Y
Do you randomize/zero the From field? - N
Do you set the Seqno field? - Y
Do you randomize the Seqno field? - Y*
Do you modify From/Seqno data upon propagation? - N
(*) Randomize on startup, then increment

jrhea · 2020-07-23T23:28:16Z

Based on the answers, it looks like none of the implementations modify seqno on propagation; however, I have seen it happen on Altona. Strange...

protolambda · 2020-07-23T23:39:53Z

@jrhea thanks for looking into the data! Those may be from the validators that got slashed, and were publishing double attestations. There's a chance you produce the same vote (not slashable, by luck) when running duplicate nodes, resulting in two messages with same contents, but different seqno.

Can you show the distribution of seqno for those messages? We can narrow down which clients are affected based on the seqno range (prysm uses initial nanosecond time, teku inits with random and keeps incrementing, others always random)

AgeManning · 2020-07-23T23:50:13Z

Most of ours looks correct. On altona we set a 0 multihash/PeerId as the author rather than randomizing it. We dont modify the sequence number when propagating.

jrhea · 2020-07-24T00:16:52Z

Those may be from the validators that got slashed, and were publishing double attestations. There's a chance you produce the same vote (not slashable, by luck) when running duplicate nodes, resulting in two messages with same contents, but different seqno.

This dataset only contains blocks

Can you show the distribution of seqno for those messages? We can narrow down which clients are affected based on the seqno range (prysm uses initial nanosecond time, teku inits with random and keeps incrementing, others always random)

Sure can...I had something like that in the works, but didn't get a chance to circle back to it today. Will take a look tonight.

protolambda · 2020-07-24T00:46:03Z

This dataset only contains blocks

Whoops, my bad. The same can still happen with double block proposals though.

Will take a look

Awesome, thanks

jrhea · 2020-07-24T06:08:26Z

Creating a compelling visual to provide the distribution of seqnos by client was non-trival (or i am just too tired). Instead, I have a visual of the distribution of message id's with multiple seqnos by client. btw, I have issues staying connected with Teku 😶 that's why it is not in the data.

To orient you, this is what the data looks like in a table after some massaging:

Here is the same data visualized with a heatmap:

At first, it looks like Lighthouse is the main culprit, but let's see what fraction of total messages were received by each client:

The distribution isn't exactly uniform so I normalize it and attempt the heatmap visualization again:

This normalized view of the data doesn't provide overwhelming evidence of anything, but it does indicate that Nimbus might be the culprit (I wouldn't exactly bet my life on it though). One more interesting fact, there isn't a single message-id with multiple sequence numbers that wasn't delivered by Nimbus at least one time. Remember the table I posted at the beginning of this comment? None of the rows have a 0 in the Nimbus column 🤷‍♂️.

Otoh, these modified message-ids with modified seqno's only make up ~ 3% of the messages received from nimbus so I don't know how compelling this really is. That being said, it is all i have right now and maybe @dryajov wouldn't mind double checking the nimbus logic to see if it possibly is modifying seqno. In the meantime, I will be in a straight jacket in a padded room.

dryajov · 2020-07-24T07:39:56Z

@jrhea, any way we can check the timestamp of the message?

We only recently (~2w ago) added proper message id generation, before it used to be the default seqno+peerid, so we might have been forwarding/generating duplicate messages. There was also another (~1w ago) recent change, which reverted our seqno to a simple counter that restarts on each run, before it used to be a randomly generated number.

Sorry for the vague dates and I'll try to get to the bottom of this in the morning, but I suspect that any or both of this changes might have had something to do with it. Thanks for the heads up 👍

jrhea · 2020-07-24T15:01:39Z

@jrhea, any way we can check the timestamp of the message?

Sure thing! Here are the min and max timestamps for nimbus messages that I collected

min: Saturday, July 18, 2020 11:52:42.804 AM
max: Monday, July 20, 2020 10:58:31.662 AM

Not sure if that lines up or if the changes made it to Altona nodes. Lmk if you need more info about the nodes.

AgeManning · 2020-08-24T07:31:42Z

Forgot to update lighthouse's side:

Is Signature required to be present?: N (at some point we can reject messages that have signatures)
Is Signature verified, if present?: N
Is Seqno required to be present?: N (at some point we can reject messages that have seq no)
Is From required to be present?: N (at some point we can reject messages that have from )
Do you set the From field?: Y (we use an identity peer_id - but will remove this as other clients appear to support no from field)
Do you randomize/zero the From field?: N
Do you set the Seqno field?: Y (we use a random number, but will remove this, once supported by Teku)
Do you randomize the Seqno field?: Y
Do you modify From/Seqno data upon propagation?: N

protolambda · 2020-08-24T14:13:08Z

@AgeManning Thanks, updated the table

Teku is now the only one in the table still requiring one of the fields: the seqno is still required to be present. @Nashatyrev is this still the case? Can you check if the table matches Teku?

Once Teku allows the seqno to be missing, all clients do not require the fields anymore, and we can plan a grace period: we give users time to update their nodes, and then start leaving out the fields of the messages after the period is over. During this grace period we can do some testing on a devnet (maybe reuse https://github.com/protolambda/fafafa) to see if the new behavior works as expected.

Nashatyrev · 2020-08-26T17:56:02Z

@protolambda
Update from Teku:

Teku:

Is Seqno required to be present? - N

protolambda · 2020-09-03T13:44:11Z

@Nashatyrev is there an option to omit the seqno yet? It looks like it is still setting it (a new one is generated if you ask it to not have a seqno): https://github.com/libp2p/jvm-libp2p/blob/c0cfb97e68f83f363063c15ca7614df95aa4ce55/src/main/kotlin/io/libp2p/pubsub/PubsubApiImpl.kt#L46

In the near future messages with seqno will be invalid, so it is important to coordinate the changes and current behavior of clients here. With testing soon hopefully as well, working on that.

Edit: also, upon propagation, these fields should be omitted (completely, i.e. exclude the optional protobuf key-value completely, not just an empty value)

Nashatyrev · 2020-09-07T13:11:33Z

Hey @protolambda, no Teku doesn't have this option yet. To make a PR I'd like to clarify a couple of questions below:

In the near future messages with seqno will be invalid

Does the same apply to From and Signature ?

Edit: also, upon propagation, these fields should be omitted

I see 2 options with this regard:

If From, Sig or SeqNo field is not nil then the message assumed invalid (and correspondingly not propagated)
Nullify From, Sig and SeqNo fields of inbound message and then propagate it. (message is not assumed invalid)

I thought we were going to stick to the option (1). Am I missing something?

protolambda · 2020-09-07T21:53:29Z

@Nashatyrev

Does the same apply to From and Signature ?

Yes, the intention is to omit all unused (w.r.t. eth2) optional (w.r.t. gossipsub) fields.

I see 2 options with this regard:

Intention is indeed option (1). We could do option (2) without breaking anything, but if nobody adds these fields to begin with, that is much cleaner (no extra data that is known to be unused for good reasons).

What I meant with "upon propagation" is that even if you didn't create the message, and are propagating it, that the fields should not be added to the message (assuming the message was valid, and didn't contain the fields to begin with).

Also, to clarify just in case, there is a difference between an empty value, and a nil value: the gossip message fields are optional and we should be able to completely omit the key-value pair. In go it's a difference between []byte (empty value, present key) and nil (fully omitted) as value. I'm not sure how it works in Java, maybe a similar pattern with null or Optional works.

One point of concern though is that if fields are unrecognized (i.e. a gossipsub implementation using a protobuf definition that does not include these optional fields), and if the fields are still passed along, then we have an issue when it comes to peer-scoring: a peer may unknowingly propagate messages with unasked for fields. This may be the case with Nimbus.

Also, now I wonder what happens if other unknown indices are used as keys for protobuf entries, and happen to be propagated (I think in Go this would happen through the XXX_unrecognized field that holds the unrecognized data). These could function like "trackers" attached to messages, and with some malicious intent, help identify the peer relations between external nodes.

I'll raise this during the networking call, some thought and questions from others definitely helps (thanks @Nashatyrev). And I am personally not a fan of protobuf for protocols like this.

Nashatyrev · 2020-09-08T16:57:55Z

@protolambda just merged the Teku PR above.
Teku now doesn't set From, Sig and SeqNo fields.
However it still doesn't deny messages with fields and propagating them 'as is'. This is a temporary solution and we will change Teku to drop such messages as soon as all clients update. Patching inbound messages (nullify their fields) for further propagation would require some extra effort on Libp2p and Teku side so we'd better wait for other clients to update.

protolambda · 2020-09-14T21:44:20Z

Opened a libp2p specs PR to standardize the policies around these fields and signature checking: libp2p/specs#294

## Issue Addressed N/A ## Proposed Changes This will consider all gossipsub messages that have either the `from`, `seqno` or `signature` field as invalid. ## Additional Info We should not merge this until all other clients have been sending empty fields for a while. See ethereum/consensus-specs#1981 for reference

Squashed commit of the following: commit 74ed1be Author: pawan <[email protected]> Date: Tue Sep 22 19:27:14 2020 +0530 fmt commit d61f956 Author: pawan <[email protected]> Date: Tue Sep 22 19:03:16 2020 +0530 Fix merge issues commit 282a973 Merge: 6759bd1 a97ec31 Author: pawan <[email protected]> Date: Tue Sep 22 18:30:10 2020 +0530 Merge branch 'master' into directory-restructure commit a97ec31 Author: Pawan Dhananjay <[email protected]> Date: Tue Sep 22 07:29:34 2020 +0000 Subscribe to subnets an epoch in advance (#1600) ## Issue Addressed N/A ## Proposed Changes Subscibe to subnet an epoch in advance of the attestation slot instead of 4 slots in advance. commit 7aceff4 Author: Michael Sproul <[email protected]> Date: Tue Sep 22 05:40:04 2020 +0000 Add `safe_sum` and use it in state_processing (#1620) ## Issue Addressed Closes #1098 ## Proposed Changes Add a `SafeArithIter` trait with a `safe_sum` method, and use it in `state_processing`. This seems to be the only place in `consensus` where it is relevant -- i.e. where we were using `sum` and the integer_arith lint is enabled. ## Additional Info This PR doesn't include any Clippy linting to prevent `sum` from being called. It seems there is no existing Clippy lint that suits our purpose, but I'm going to look into that and maybe schedule writing one as a lower-priority task. This theoretically _is_ a consensus breaking change, but it shouldn't impact Medalla (or any other testnet) because `slashings` shouldn't overflow! commit 4fca306 Author: Michael Sproul <[email protected]> Date: Tue Sep 22 05:40:02 2020 +0000 Update BLST, add force-adx support (#1595) ## Issue Addressed Closes #1504 Closes #1505 ## Proposed Changes * Update `blst` to the latest version, which is more portable and includes finer-grained compilation controls (see below). * Detect the case where a binary has been explicitly compiled with ADX support but it's missing at runtime, and report a nicer error than `SIGILL`. ## Known Issues * None. The previous issue with `make build-aarch64` (supranational/blst#27), has been resolved. ## Additional Info I think we should tweak our release process and our Docker builds so that we provide two options: Binaries: * `lighthouse`: compiled with `modern`/`force-adx`, for CPUs 2013 and newer * `lighthouse-portable`: compiled with `portable` for older CPUs Docker images: * `sigp/lighthouse:latest`: multi-arch image with `modern` x86_64 and vanilla aarch64 binary * `sigp/lighthouse:latest-portable`: multi-arch image with `portable` builds for x86_64 and aarch64 And relevant Docker images for the releases (as per #1574 (comment)), tagged `v0.x.y` and `v0.x.y-portable` commit d85d5a4 Author: Paul Hauner <[email protected]> Date: Tue Sep 22 04:45:15 2020 +0000 Bump to v0.2.11 (#1645) ## Issue Addressed NA ## Proposed Changes - Bump version to v0.2.11 - Run `cargo update`. ## Additional Info NA commit bd39cc8 Author: Paul Hauner <[email protected]> Date: Tue Sep 22 02:06:10 2020 +0000 Apply hotfix for inconsistent head (#1639) ## Issue Addressed - Resolves #1616 ## Proposed Changes If we look at the function which persists fork choice and the canonical head to disk: https://github.com/sigp/lighthouse/blob/1db8daae0c7bb34bf2e05644fa6bf313c2bea98e/beacon_node/beacon_chain/src/beacon_chain.rs#L234-L280 There is a race-condition which might cause the canonical head and fork choice values to be out-of-sync. I believe this is the cause of #1616. I managed to recreate the issue and produce a database that was unable to sync under the `master` branch but able to sync with this branch. These new changes solve the issue by ignoring the persisted `canonical_head_block_root` value and instead getting fork choice to generate it. This ensures that the canonical head is in-sync with fork choice. ## Additional Info This is hotfix method that leaves some crusty code hanging around. Once this PR is merged (to satisfy the v0.2.x users) we should later update and merge #1638 so we can have a clean fix for the v0.3.x versions. commit 14ff385 Author: Pawan Dhananjay <[email protected]> Date: Tue Sep 22 01:12:36 2020 +0000 Add trusted peers (#1640) ## Issue Addressed Closes #1581 ## Proposed Changes Adds a new cli option for trusted peers who always have the maximum possible score. commit 5d17eb8 Author: Michael Sproul <[email protected]> Date: Mon Sep 21 11:53:53 2020 +0000 Update LevelDB to v0.8.6, removing patch (#1636) Removes our dependency on a fork of LevelDB now that skade/leveldb-sys#17 is merged commit 1db8daa Author: Age Manning <[email protected]> Date: Mon Sep 21 02:00:38 2020 +0000 Shift metadata to the global network variables (#1631) ## Issue Addressed N/A ## Proposed Changes Shifts the local `metadata` to `network_globals` making it accessible to the HTTP API and other areas of lighthouse. ## Additional Info N/A commit 7b97c4a Author: Pawan Dhananjay <[email protected]> Date: Mon Sep 21 01:06:25 2020 +0000 Snappy additional sanity checks (#1625) ## Issue Addressed N/A ## Proposed Changes Adds the following check from the spec > A reader SHOULD NOT read more than max_encoded_len(n) bytes after reading the SSZ length-prefix n from the header. commit 371e1c1 Author: Paul Hauner <[email protected]> Date: Fri Sep 18 06:41:29 2020 +0000 Bump version to v0.2.10 (#1630) ## Issue Addressed NA ## Proposed Changes Bump crate version so we can cut a new release with the fix from #1629. ## Additional Info NA commit a17f748 Author: Paul Hauner <[email protected]> Date: Fri Sep 18 05:14:31 2020 +0000 Fix bad assumption when checking finalized descendant (#1629) ## Issue Addressed - Resolves #1616 ## Proposed Changes Fixes a bug where we are unable to read the finalized block from fork choice. ## Detail I had made an assumption that the finalized block always has a parent root of `None`: https://github.com/sigp/lighthouse/blob/e5fc6bab485fa54d7e518b325f4eb9201ba5c6a1/consensus/fork_choice/src/fork_choice.rs#L749-L752 This was a faulty assumption, we don't set parent *roots* to `None`. Instead we *sometimes* set parent *indices* to `None`, depending if this pruning condition is satisfied: https://github.com/sigp/lighthouse/blob/e5fc6bab485fa54d7e518b325f4eb9201ba5c6a1/consensus/proto_array/src/proto_array.rs#L229-L232 The bug manifested itself like this: 1. We attempt to get the finalized block from fork choice 1. We try to check that the block is descendant of the finalized block (note: they're the same block). 1. We expect the parent root to be `None`, but it's actually the parent root of the finalized root. 1. We therefore end up checking if the parent of the finalized root is a descendant of itself. (note: it's an *ancestor* not a *descendant*). 1. We therefore declare that the finalized block is not a descendant of (or eq to) the finalized block. Bad. ## Additional Info In reflection, I made a poor assumption in the quest to obtain a probably negligible performance gain. The performance gain wasn't worth the risk and we got burnt. commit 49ab414 Author: Age Manning <[email protected]> Date: Fri Sep 18 02:05:36 2020 +0000 Shift gossipsub validation (#1612) ## Issue Addressed N/A ## Proposed Changes This will consider all gossipsub messages that have either the `from`, `seqno` or `signature` field as invalid. ## Additional Info We should not merge this until all other clients have been sending empty fields for a while. See ethereum/consensus-specs#1981 for reference commit 2074bec Author: Age Manning <[email protected]> Date: Fri Sep 18 02:05:34 2020 +0000 Gossipsub message id to shortened bytes (#1607) ## Issue Addressed ethereum/consensus-specs#2044 ## Proposed Changes Shifts the gossipsub message id to use the first 8 bytes of the SHA256 hash of the gossipsub message data field. ## Additional Info We should merge this in once the spec has been decided on. It will cause issues with gossipsub scoring and gossipsub propagation rates (as we won't receive IWANT) messages from clients that also haven't made this update. commit e5fc6ba Author: Michael Sproul <[email protected]> Date: Mon Sep 14 10:58:15 2020 +0000 Remove redundant decompression in process_deposit (#1610) ## Issue Addressed Closes #1076 ## Proposed Changes Remove an extra unnecessary decompression of the deposit public key from `process_deposit`. The key is decompressed and used to verify the signature in `verify_deposit_signature`, making this initial decompression redundant. ## Additional Info This is _not_ a consensus-breaking change because keys which previously failed the early decompression check will not be found in the pubkey cache (they are invalid), and will be checked and rejected as part of `verify_deposit_signature`. commit c9596fc Author: Age Manning <[email protected]> Date: Sun Sep 13 23:58:49 2020 +0000 Temporary Sync Work-Around (#1615) ## Issue Addressed #1590 ## Proposed Changes This is a temporary workaround that prevents finalized chain sync from swapping chains. I'm merging this in now until the full solution is ready. commit c6abc56 Author: Age Manning <[email protected]> Date: Fri Sep 11 02:33:36 2020 +0000 Prevent large step-size parameters (#1583) ## Issue Addressed Malicious users could request very large block ranges, more than we expect. Although technically legal, we are now quadraticaly weighting large step sizes in the filter. Therefore users may request large skips, but not a large number of blocks, to prevent requests forcing us to do long chain lookups. ## Proposed Changes Weight the step parameter in the RPC filter and prevent any overflows that effect us in the step parameter. ## Additional Info commit 7f1b936 Author: blacktemplar <[email protected]> Date: Fri Sep 11 01:43:15 2020 +0000 ignore too early / too late attestations instead of penalizing them (#1608) ## Issue Addressed NA ## Proposed Changes This ignores attestations that are too early or too late as it is specified in the spec (see https://github.com/ethereum/eth2.0-specs/blob/v0.12.1/specs/phase0/p2p-interface.md#global-topics first subpoint of `beacon_aggregate_and_proof`) commit 810de2f Author: Daniel Schonfeld <[email protected]> Date: Fri Sep 11 01:43:13 2020 +0000 Static testnet configs (#1603) ## Issue Addressed #1431 ## Proposed Changes Added an archived zip file with required files manually ## Additional Info 1) Used zip, instead of tar.gz to add a single dependency instead of two. 2) I left the download from github code for now, waiting to hear if you'd like it cleaned up or left to be used for some tooling needs. commit 0525876 Author: Pawan Dhananjay <[email protected]> Date: Fri Sep 11 00:52:27 2020 +0000 Dial cached enr's before making subnet discovery query (#1376) ## Issue Addressed Closes #1365 ## Proposed Changes Dial peers in the `cached_enrs` who aren't connected, aren't banned and satisfy the subnet predicate before making a subnet discovery query. commit d79366c Author: Age Manning <[email protected]> Date: Thu Sep 10 04:43:22 2020 +0000 Prevent printing binary in RPC errors (#1604) ## Issue Addressed #1566 ## Proposed Changes Prevents printing binary characters in the RPC error response from peers. commit b19cf02 Author: Age Manning <[email protected]> Date: Thu Sep 10 03:51:06 2020 +0000 Penalise bad peer behaviour (#1602) ## Issue Addressed #1386 ## Proposed Changes Penalises peers in our scoring system that produce invalid attestations or blocks. commit dfe5077 Author: Paul Hauner <[email protected]> Date: Thu Sep 10 00:24:41 2020 +0000 Remove references to rust-docs (#1601) ## Issue Addressed - Resolves #897 - Resolves #821 ## Proposed Changes Removes references to the rust docs that we're no long maintaining. ## Additional Info NA commit 0821e6b Author: Paul Hauner <[email protected]> Date: Wed Sep 9 02:28:35 2020 +0000 Bump version to v0.2.9 (#1598) ## Issue Addressed NA ## Proposed Changes - Bump version tags - Run `cargo update` ## Additional Info NA commit 6759bd1 Author: pawan <[email protected]> Date: Tue Sep 8 12:39:22 2020 +0530 Add `strict-slashing-protection` flag commit 1644717 Author: pawan <[email protected]> Date: Fri Sep 4 16:46:43 2020 +0530 Remove `get_default_base_dir` commit e4783bf Author: pawan <[email protected]> Date: Fri Sep 4 16:24:45 2020 +0530 Address review comments commit 89b832c Author: pawan <[email protected]> Date: Thu Sep 3 00:30:53 2020 +0530 Fix tests commit 5940a52 Author: pawan <[email protected]> Date: Wed Sep 2 21:27:57 2020 +0530 Print out path information in account manager commit 5ca1341 Author: pawan <[email protected]> Date: Wed Sep 2 20:49:29 2020 +0530 Use datadir flag for account manager commit 8c82769 Author: pawan <[email protected]> Date: Wed Sep 2 20:10:44 2020 +0530 Rename BASE_DIR_FLAG to WALLET_DIR_FLAG commit ad34a0f Author: pawan <[email protected]> Date: Wed Sep 2 18:17:45 2020 +0530 Add validator-dir cli option commit 04fd9f7 Merge: 0e3ccba 8718120 Author: pawan <[email protected]> Date: Wed Sep 2 14:53:27 2020 +0530 Merge branch 'master' into directory-restructure commit 0e3ccba Author: pawan <[email protected]> Date: Wed Sep 2 14:40:36 2020 +0530 Minor fixes commit ad22178 Author: pawan <[email protected]> Date: Tue Sep 1 19:14:44 2020 +0530 Migration for ValidatorDefinitions commit 1022f58 Author: pawan <[email protected]> Date: Tue Sep 1 16:02:07 2020 +0530 Fix lints and udeps commit 4ddbbfe Author: pawan <[email protected]> Date: Tue Sep 1 12:56:12 2020 +0530 Remove more hardocoded values commit 4170e4c Author: pawan <[email protected]> Date: Tue Sep 1 12:50:43 2020 +0530 Remove some hardcoded values commit 5c46823 Merge: ae533f3 8301a98 Author: pawan <[email protected]> Date: Tue Sep 1 12:02:35 2020 +0530 Merge branch 'master' into directory-restructure commit ae533f3 Author: pawan <[email protected]> Date: Mon Aug 17 20:47:20 2020 +0530 Docs fixes commit fe13b1b Author: pawan <[email protected]> Date: Mon Aug 17 19:58:09 2020 +0530 lint commit e4a7e8c Merge: 01e6166 9a97a0b Author: pawan <[email protected]> Date: Mon Aug 17 19:47:27 2020 +0530 Merge branch 'master' into directory-restructure commit 01e6166 Author: pawan <[email protected]> Date: Mon Aug 17 19:23:57 2020 +0530 All binaries get directory info from common::directory crate commit 8a7c130 Author: pawan <[email protected]> Date: Mon Aug 17 17:18:44 2020 +0530 Add migration code for restructure commit a4c33cd Author: pawan <[email protected]> Date: Mon Aug 17 15:51:24 2020 +0530 Fix bug in secrets dir commit f4b8529 Author: pawan <[email protected]> Date: Mon Aug 17 13:05:28 2020 +0530 Restrucure validator directory paths commit 54b4ae6 Author: pawan <[email protected]> Date: Mon Aug 17 12:20:40 2020 +0530 Restructure account_manager directory paths commit 53892af Author: pawan <[email protected]> Date: Thu Aug 13 19:43:44 2020 +0530 Move get_testnet_dir to clap utils commit d1d269a Author: pawan <[email protected]> Date: Thu Aug 13 19:33:34 2020 +0530 Move beacon directory

protolambda · 2021-04-06T15:38:33Z

This was implemented in all clients, as option in libp2p, and included in the libp2p pubsub spec. Closing this old issue.

protolambda added the scope:networking label Jul 23, 2020

protolambda mentioned this issue Jul 23, 2020

Signing policy + optional Signature, From and Seqno libp2p/go-libp2p-pubsub#359

Merged

This was referenced Jul 29, 2020

internal error on message publish: IndexOutOfBoundsException Consensys/teku#2476

Closed

More flexible pubsub message fields handling libp2p/jvm-libp2p#132

Merged

hwwhww added this to the v1.0.0 milestone Aug 21, 2020

nisdas mentioned this issue Aug 24, 2020

Unset From,Sequence Number and Signature For Pubsub Messages prysmaticlabs/prysm#7093

Merged

2 tasks

protolambda mentioned this issue Sep 7, 2020

Eth2 Networking Call 5 ethereum/eth2.0-pm#180

Closed

Nashatyrev mentioned this issue Sep 8, 2020

Make optional Gossip message fields empty for outbound messages Consensys/teku#2752

Merged

1 task

AgeManning mentioned this issue Sep 11, 2020

[Merged by Bors] - Shift gossipsub validation sigp/lighthouse#1612

Closed

hwwhww added the scope:privacy label Sep 12, 2020

protolambda mentioned this issue Sep 14, 2020

gossipsub v1.1: introduce message signing policy libp2p/specs#294

Merged

protolambda mentioned this issue Sep 14, 2020

Use gossip signing policy in p2p spec, see libp2p/specs#294 #2060

Merged

hwwhww added the scope:libp2p label Sep 15, 2020

oskarth mentioned this issue Sep 22, 2020

Waku v2: Decide what to do about seqno field vacp2p/rfc#149

Closed

sinkingsugar mentioned this issue Sep 22, 2020

allow to omit peerId and seqno vacp2p/nim-libp2p#372

Merged

AgeManning mentioned this issue Sep 23, 2020

Gossipsub v1.1 Scoring Paramters sigp/lighthouse#1606

Closed

nisdas mentioned this issue Sep 24, 2020

Reject Messages With Invalid Fields in GossipSub prysmaticlabs/prysm#7337

Merged

Nashatyrev mentioned this issue Oct 13, 2020

Enforce StrictNoSign on gossip messages Consensys/teku#2960

Merged

1 task

hwwhww modified the milestones: 🔴 v1.0.0 required, 🔵 v1.0.0 candidates Nov 4, 2020

protolambda closed this as completed Apr 6, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

GossipSub: disabling unused From/Seqno/Signature #1981

GossipSub: disabling unused From/Seqno/Signature #1981

protolambda commented Jul 23, 2020

protolambda commented Jul 23, 2020 •

edited

Loading

dryajov commented Jul 23, 2020

protolambda commented Jul 23, 2020

dryajov commented Jul 23, 2020

wemeetagain commented Jul 23, 2020

Nashatyrev commented Jul 23, 2020

jrhea commented Jul 23, 2020 •

edited

Loading

protolambda commented Jul 23, 2020

AgeManning commented Jul 23, 2020

jrhea commented Jul 24, 2020

protolambda commented Jul 24, 2020

jrhea commented Jul 24, 2020 •

edited

Loading

dryajov commented Jul 24, 2020

jrhea commented Jul 24, 2020

AgeManning commented Aug 24, 2020

protolambda commented Aug 24, 2020

Nashatyrev commented Aug 26, 2020

protolambda commented Sep 3, 2020 •

edited

Loading

Nashatyrev commented Sep 7, 2020

protolambda commented Sep 7, 2020

Nashatyrev commented Sep 8, 2020

protolambda commented Sep 14, 2020

protolambda commented Apr 6, 2021

GossipSub: disabling unused From/Seqno/Signature #1981

GossipSub: disabling unused From/Seqno/Signature #1981

Comments

protolambda commented Jul 23, 2020

protolambda commented Jul 23, 2020 • edited Loading

dryajov commented Jul 23, 2020

protolambda commented Jul 23, 2020

dryajov commented Jul 23, 2020

wemeetagain commented Jul 23, 2020

Nashatyrev commented Jul 23, 2020

jrhea commented Jul 23, 2020 • edited Loading

protolambda commented Jul 23, 2020

AgeManning commented Jul 23, 2020

jrhea commented Jul 24, 2020

protolambda commented Jul 24, 2020

jrhea commented Jul 24, 2020 • edited Loading

dryajov commented Jul 24, 2020

jrhea commented Jul 24, 2020

AgeManning commented Aug 24, 2020

protolambda commented Aug 24, 2020

Nashatyrev commented Aug 26, 2020

protolambda commented Sep 3, 2020 • edited Loading

Nashatyrev commented Sep 7, 2020

protolambda commented Sep 7, 2020

Nashatyrev commented Sep 8, 2020

protolambda commented Sep 14, 2020

protolambda commented Apr 6, 2021

protolambda commented Jul 23, 2020 •

edited

Loading

jrhea commented Jul 23, 2020 •

edited

Loading

jrhea commented Jul 24, 2020 •

edited

Loading

protolambda commented Sep 3, 2020 •

edited

Loading