Party ID logged during TSS signing is no the same as on-chain index of a member

[pdyraga]

#616 calculates the order in which signers should submit a signature by determining signer's position in address[] public members field of AbstractBondedECDSAKeep and then calculating the delay based on signer's index:

keep-ecdsa/pkg/node/node.go

Lines 465 to 478 in 7062199

	func (n *Node) getSignerIndex(keepAddress common.Address) (int, error) {
	members, err := n.ethereumChain.GetMembers(keepAddress)
	if err != nil {
	return -1, err
	}
	for index, member := range members {
	if member == n.ethereumChain.Address() {
	return index, nil
	}
	}
	return -1, nil
	}

keep-ecdsa/pkg/node/node.go

Line 454 in 7062199

delay := time.Duration(signerIndex) * signaturePublicationDelayStep

Looking into logs, it seems that the signer that was identified as tss-lib party {2,} during the signature generation has index 0 in the array array returned from GetMembers(). Signer that was identified as tss-lib party {1,} has index 1 in that array and the signer that was identified as tss-lib party {0,} has index 2 in that array:

2020-11-23T12:08:12.948+0100	INFO	tss-lib	party {2,}: signing finished!
2020-11-23T12:08:12.956+0100	INFO	keep-ecdsa	waiting [0s] before publishing signature for keep [0xe1C664a63BD1D017270aaE9bda45A776bA86a078]

020-11-23T11:22:10.222+0100	INFO	tss-lib	party {1,}: signing finished!
2020-11-23T11:22:10.226+0100	INFO	keep-ecdsa	waiting [5m0s] before publishing signature for keep [0xe1C664a63BD1D017270aaE9bda45A776bA86a078]

2020-11-23T11:22:10.226+0100	INFO	tss-lib	party {0,}: signing finished!
2020-11-23T11:22:10.229+0100	INFO	keep-ecdsa	waiting [10m0s] before publishing signature for keep [0xe1C664a63BD1D017270aaE9bda45A776bA86a078]

This is confusing and can potentially mislead during problem debugging or when recovering from an issue.

We should make sure party ID logged during tss signing is the same as the index under which the given member is stored on-chain.

Important: This may not be just a logging problem. When working on this issue make sure the change is backward-compatible and two clients in different versions can still generate a signature.