ethereum/eth2.0-pm#131
<sly> I can't find it in the spec, but I presume the intention is that clients keep a record of SignedBeaconBlock that they receive, so that they can respond to requests such as BeaconBlocksByRange.
The spec says clients must support the request, and respond if they have the requested signed blocks, but there is nothing in the spec that requires them to keep a record of signed blocks. (Fork Choice only requires a record of BeaconBlock, not the signed envelope.)
MUST in the p2p spec as constraining clients to keep the signed block data
<djrtwo> Networking call in about 13.5 hours
ethereum/eth2.0-pm#131
Top priority -- iron out how to use fork_version in planned forks, across chains, and other usecases. I have a proposal to start us off and we can go from there
Then we can get the last couple of PRs cleaned and merged
If I qualify as "people" 😂
- discv5 to have an update in two weeks
- Discussions on fork_id / chain_id
- REPL update from proto https://github.com/protolambda/rumor
- Discussion on adding ENR on status message https://github.com/ethereum/eth2.0-pm/issues/131#issuecomment-594313516
- Age Mannig reporting incompatibilities b/w go noise and rust noise
- Further discussions on ENR and metadata.
<sly> Done as issues. I'm happy to work on an actual PR after feedback if people think it is worth it.
The issues are relatively minor (i.e. nothing is broken), except for the current Dev branch changes to Store for block headers, but that is probably a work in progress (I didnt' see a PR or branch, but someone may be working on it privately).
<sly> Done as issues. I'm happy to work on an actual PR after feedback if people think it is worth it.
The issues are relatively minor (i.e. nothing is broken), except for the current Dev branch changes to Store for block headers, but that is probably a work in progress (I didn't see a PR or branch, but someone may be working on it privately).
