Add a note on sig existence guarantees

[oggy-dfin]

Previously we didn't specify anything about what happens when a call to a signing point fails for whatever reason. Clarify to say that we don't guarantee that no signature was computed, so that applications don't rely on this signature being unique.

Thank you for your contribution to the IC Developer Portal. This repo contains the content for https://internetcomputer.org and the ICP Developer Documentation, https://internetcomputer.org/docs/.

If you are submitting a pull request for adding or changing content on the ICP Developer Documentation, please make sure that your contribution meets the following requirements:

• [ ] Follows the developer docs style guide.
• [ ] Follows the best practices and guidelines.
• [ ] New documentation pages include document tags.
• [ ] New documentation pages include SEO keywords.
• [ ] New documents are in the .mdx file format to support the previous two components.
• [ ] New documents are registered in /sidebars.js, otherwise, it will not appear in the side navigation bar.
• [ ] Make sure that the .github/CODEOWNERS file is contains any new directories or specific documents that you added that should be reviewed by a specific teamm.

[gregorydemay]

When we say "Note that, in some cases" we could maybe mention/link to bounded-wait calls? In general, my understanding was that we would make the documentation more explicit about using bounded-wait calls and threshold signatures. Do you plan to add anything specific in the documentation of bounded-wait calls?

I also find the addition, while worthwhile, not specific enough. I think we should have a table comparing threshold signatures with bounded-wait calls vs unbounded-wait calls.

[oggy-dfin]

Sorry, dropped the ball on this one. Would the following formulation be satisfactory?

Note that, in some cases, a signature may be computed when requested, but not returned to the requesting canister. Thus, canisters should not rely on the signature not existing even if the signing request fails. In particular, the signature existing despite the signing request failing is more likely to happen if the request is made using a bounded-wait call to the management canister which times out. However, it may also happen in other request failure cases too (regardless of the whether the request was done using a bounded- or unbounded-wait call).

@andreacerulli @gregorydemay

[gregorydemay]

Thanks @oggy-dfin for the new formulation! My problem with it is that it's very vague: "in some cases", "more likely to happen", "may also happen in other request failure cases". But actually, we know exactly under which circumstances this type of behaviour may occur. As I mentioned in my previous message, I think a table comparing the guarantees of threshold signing under bounbed/unbounded wait calls would bring more clarity.