chore: do not require identical git hash during DKG

[dpc]

That is waay to constraining. Different peers can't even include non-code fixes for their local deployement and other problems.

Since we're kind of good at the release and versioning and stability things, change the requirement to a code_version_str, which consists of the cargo release version of Fedimint code and optional vendor suffix.

[douglaz]

Yeah, it makes sense to allow different git versions.

But now it's not clear if we support the following scenario:

So I create a new fedimintd with a new module and try to setup with the vanilla fedimintd (perhaps accepting the standard modules). Will this ceremony work?

[dpc]

So I create a new fedimintd with a new module and try to setup with the vanilla fedimintd (perhaps accepting the standard modules). Will this ceremony work?

Nope. As things are right now, we don't have any way for peers to vote/agree on a common set and composition of modules, so they have to be exactly the same everywhere. That's the whole reason we enforced the same hash to being with. I'm just relaxing it a bit.

Maybe one day thought. Then we can remove the whole requirement, and each module will be negotiated independently etc.

[elsirion]

Maybe one day thought. Then we can remove the whole requirement, and each module will be negotiated independently etc.

The leader should likely select the modules, they already choose module parameters.

[fedimint-backports]

Backport failed for releases/v0.3, because it was unable to cherry-pick the commit(s).

Please cherry-pick the changes locally and resolve any conflicts.

git fetch origin releases/v0.3
git worktree add -d .worktree/backport-5313-to-releases/v0.3 origin/releases/v0.3
cd .worktree/backport-5313-to-releases/v0.3
git switch --create backport-5313-to-releases/v0.3
git cherry-pick -x 0800e73e7641d488e14e02294574ff489e3e56e2

[dpc]

I don't think we really need to backport it. People lived with it since now, so they can wait ~2 months for 0.4.