feat(test):sign result

[ggutoski]

This PR is a repeat of #44 . That PR was reverted due to #50 . Build is broken in this branch after merging #52 . I rebased onto master.

[sdaveas]

Fixed the breaking code and added meaningful checks of sign result.

[sdaveas]

closes #42

[ggutoski]

Did you ever observe duplicates? We should probably fail the test here if this list contains duplicates.

[sdaveas]

Yes, there is a single entry for each share of the malicious party.

[ggutoski]

As discussed, more investigation is needed here. Each party runs multiple shares, but this code breaks on the first occurrence of SignResult, so we should only ever see one copy of the result. (Hence we should not have duplicates in the criminals list.) Perhaps we should switch to a wait group here similar to what's in production code. In any case, we don't have an explanation for why you are observing duplicates in the criminals list.

[sdaveas]

The result contains the uid of the criminal one time for each of his shares. I think it's logical because all shares that belong to the malicious party are registered as individual criminals, and multiple shares map to the same uid.

Example: if a malicious party A has shares with tofn indices 0,1,2, the criminal_list will contain [0:Malicious, 1:Malicious, 2:Malicious] (which correspond to [tofn_index, CrimeType] for each pair).

In tofnd, we examine the uid of the criminal, rather than his tofn share indices. This means that the criminal vector will become [A:Malicious, A:Malicious, A:Malicious] (which correspond to [tofnd_index, CrimeType] for each pair).

[sdaveas]

The conversion from tofnd to tofn index happens here:

tofnd/src/gg20/proto_helpers.rs

Lines 71 to 76 in 192d954

	let (criminal_index, _) = map_tofn_to_tofnd_idx(c.index, all_share_counts)
	.expect("failure to recover tofnd party index from tofn share index");
	ProtoCriminal {
	party_uid: participant_uids[criminal_index].clone(),
	crime_type: ProtoCrimeType::from(c.crime_type) as i32, // why `as i32`? https://github.com/danburkert/prost#enumerations
	}

[ggutoski]

Thank you! As discussed, we need to decide how to report the criminals list to axelar-core:

• Criminals[A:0, A:1, B:0, B:1], or
• Criminals[A, B]

[ggutoski]

Related: we also need to decide how tofnd should implement malicious behaviour over multiple subshares:

• all subshares do the same malicious behaviour
• only one subshare is malicious (eg. the 0th subshare), all other's are honest
• something else?

[sdaveas]

Option 1 is the simplest case for the current codebase in tofnd. Let's start with that and see if we need to fallback to option 2?

[ggutoski]

Reminder: Please do not merge until we've run a local cluster test with axelar-core.