search

mimblewimble / grin

Minimal implementation of the Mimblewimble protocol.
https://grin.mw/
Apache License 2.0
5.04k stars 990 forks source link

P2P Protocol Version for HF4 #3430

Open antiochp opened 4 years ago

antiochp commented 4 years ago

Nodes are currently on p2p protocol version 2.

See associated RFC for details on "variable size kernels" - https://github.com/mimblewimble/grin-rfcs/pull/21

We are ~proposing~ bumping to version 3: "commit only inputs". DONE/MERGED. See #3419 for details on this.

https://github.com/mimblewimble/docs/wiki/P2P-Protocol#phasing-out-old-peers

In line with our protocol version major/minor versioning strategy we should consider bumping to version 1000 as part of our final scheduled HF, or potentially as part of 4.x.0 and a final bump to version 2000 at HF4. This would force all nodes post HF4 to support only the latest, most recent, p2p protocol version.

It would be convenient if we could take advantage of the final scheduled HF to "lock" the supported protocol version. This would allow for legacy code to be cleaned up after HF4 with some confidence that old nodes will no longer need to be supported.

Post HF4 we will have no need to support either legacy "fixed size kernels" or legacy "features and commit inputs".

antiochp commented 4 years ago

cc @DavidBurkett and @davidtavarez

DavidBurkett commented 4 years ago

Our latest Grin++ versions are already doing variable-sized kernels, and I'm comfortable committing to supporting the new protocol version 3 as well.

It seems unnecessary to force such a rapid jump in protocol versions to kill old peers. I expected those kinds of major jumps to be saved for cases where there's an extraordinary amount of code for supporting the old versions or a noticeable decrease in network chattiness or performance increase as a result of an upgrade. If we do decide to increase the protocol version by 1-2K anyway, we'll keep Grin++ consistent.

antiochp commented 4 years ago

It seems unnecessary to force such a rapid jump in protocol versions to kill old peers.

We could alternatively just implement an HF4 specific rule that peers are incompatible with older protocol versions, but it makes sense to take advantage of the existing rules I think.