eth/protocols/eth: drop protocol version eth/68#33511
Conversation
|
We should ask other client teams if they have shipped eth69 before the Osaka fork. It's safer to deprecate eth68 if the majority of clients have eth69 available. |
When I checked the hive tests, all clients except Erigon were able to be connected using StatusPacket69 and process BlockRangeUpdatePacket messages. For Erigon we can ask, but I think we can at least say that most clients have implemented eth/69. |
d65506c to
7f09355
Compare
|
Commit
|
| } | ||
| } | ||
|
|
||
| // Tests that synchronisations behave well in multi-version protocol environments |
There was a problem hiding this comment.
I removed this because the purpose of this test was checking how sync behaves with peers which have different protocol versions. However, the test was only using one peer, and it was now labeled as "peer 68" but used eth/69. Best to just remove it.
It's better to have only one type for receipt requests.
I didn't like that the test needed a special receipt list type for hashing. It should use the protocol types as much as possible.
I didn't like the new name and the comment was wrong.
conventionally, the constructor definition should be as close as possible to the type definition
This PR drops support for eth68.