Implement LLMQ DKG

[codablock]

This is extracted from #2311 and only contains the DKG. It also removes the dummy DKG in the first commit.

It does not contain the signing sessions code as I'm planning to create another PR for this.

[UdjinM6]

Just some general comments for now, will take some time to dig in and do a full review 😅

[UdjinM6]

Why using some new library for timers instead of simply

int64_t nTimeStart = GetTimeMillis();
// some code
LogPrintf("Some code took %dms\n", GetTimeMillis() - nTimeStart);

like we already do?

[codablock]

Because a class for timers makes using them a lot easier, especially when you have multiple timers per method and need to start/stop them in different places. I initially thought about implementing my own timer class, but then found this header-only "library" and took it instead.

[UdjinM6]

2 suggestions to fix compilation issues

[UdjinM6]

I have few patches and one question so far :)

• 4ead34438 Batched logger should not break log parsing
• e4c1b02da Add some consts
• ed00a9761 some trivial cleanup

[UdjinM6]

Few more small suggestions

[UdjinM6]

A couple of suggestions to fix quorum dkgstatus help message format to match the one used in other places and a question regarding "0", see below.

[UdjinM6]

Suggesting another few patches after the discussion in previous ones :)

• 0114a531a c3ade4a6a Replace Seen with AddSeenMessage and move its use out of PreVerifyMessage
• f003c1ed9 1669d6980 Add some consts (modified version)

EDIT: forgot to pull the latest changes first, fixed

[codablock]

@UdjinM6 Can you explain why c3ade4a moves the AddSeenMessage calls into SendContributions and friends? Did you try to remove the Seen logic completely and then observed double-verification/processing of the messages created by the local node?

[UdjinM6]

I just wanted to split "seen" and actual (pre)verification steps, cause it seems like they should not be coupled. Or am I missing smth?

[codablock]

Hmm, problem with that is that it doesn't do what one might expect. AddSeenMessage is now only called for the self-created message and never for one that is received. This will still work, as CDKGPendingMessages has another layer of protection against duplicate messages, but it's confusing and unexpected.

I added a commit that does a completely different thing: Instead of calling PreVerify+ReceiveMessage, SendContribution and friends will now push the message into the pendingMessages object so that the messages are processed the same way as actually received messages. This adds some overhead due to unnecessary serialization/deserialization, but I think that's ok (it's just one out of up to 400 messages). The advantage is that messages now always run through the same code path and the "seen messages" logic is applied equally to self created and received messages.

[UdjinM6]

Looks good IMO, though I'm still a bit confused with all the crypto magic happening here :D

utACK