Catch TypeError and ValueError in verify functions

[algochoi]

pynacl's VerifyKey() can now return a TypeError or ValueError (related PR). Our SDK should reflect this change by catching those errors as well, or users may encounter an unexpected exception.

Picked some major release versions and set that as boundaries. Hopefully users are using venv or conda as well...

• pynacl
• msgpack
• pycryptodomex

Also added the black formatter updates so CI can run normally.

I didn't change the v1 transaction methods, but the problem is there as well (I hope no one uses them because we haven't updated them for a very long time).

[tzaffi]

I'm guessing that most users simply want to know that verify() has failed, deal with it, and won't really care why this has occurred (at least not in their runtime handling). For such users, swallowing these two exceptions makes life easier.

But could there be something about these different errors that could allow users to have more nuanced recovery strategies? I kind of doubt it, but it's worth knowing before we just add the blanket conversion from (BadSignatureError, ValueError, TypeError) to False.

[tzaffi]

Thinking more about it, ValueError and TypeError sounds like they could be generated by bad user input/usage. If that is the case, then we really wouldn't want to swallow these errors.

[algochoi]

Good point - I also thought about this and couldn't reach a conclusive decision. Our current unit tests do seem to test the ValueError here by testing the wrong number of bytes:

py-algorand-sdk/test_unit.py

Line 2694 in f0c9430

def test_verify(self):

I'm not exactly sure how we want verify to behave in these cases so I wanted other people's inputs as well. If we choose to include this change, I can also add some test cases to check the two new error types.

[michaeldiamant]

Summarizing a verbal with @algochoi, @tzaffi, and @jasonpaulos:

• We agreed the expedient path is to keep the PR's behavior and add unit tests validating behavior.
• We left with a loose agreement that revisiting the return type out-of-band is worthwhile. For example, moving from boolean to a richer data type will simplify disambiguating failure cases.

As of c3b94a2, I think the PR matches what we verbally agreed to. Since I didn't open the thread, I'll leave as is without resolving.

[michaeldiamant]

@algochoi Thanks for the effort to clean up API inconsistencies here. ☕