md: rewrite robustness part of design section

README.md

@@ -132,29 +132,28 @@ In summary, we aim for the following design goals:
  - **Simple backups**: The capability of ChillDKG to recover devices from a static seed and public recovery data avoids the need for secret per-session backups, enhancing user experience.
  - **Untrusted coordinator**: Like FROST, ChillDKG uses a coordinator that relays messages between the participants. This simplifies the network topology, and the coordinator additionally reduces communication overhead by aggregating some of the messages. A malicious coordinator can force the DKG to fail but cannot negatively affect the security of the DKG.
  - **Per-participant public keys**: When ChillDKG is used with FROST, partial signature verification is supported.
- - **No exclusion of participants**: ChillDKG aborts in the case of protocol errors instead of trying to guarantee progress by excluding participants that appear unresponsive or faulty. In other words, ChillDKG errs on the side of caution and enables users to investigate and resolve benign faults (e.g., due to software bugs or unreliable communication links) before the key material generated by the DKG is put into production.
 
 In summary, ChillDKG incorporates solutions for both secure channels and consensus, and simplifies backups in practice.
 As a result, it fits a wide range of application scenarios,
 and due to its low overhead, we recommend ChillDKG even secure communication channels or a consensus mechanism (e.g., a BFT protocol or a reliable broadcast mechanism) is readily available.
 
 #### Why Robustness is not a Goal
 
-A direct consequence of the design goal that no participants are excluded is that ChillDKG does not provide *robustness*,
-i.e., the protocol is not guaranteed to succeed in the presence of malicious participants.[^no-identifiable-aborts]
-Indeed, a single malicious participant can force the protocol abort, e.g., by sending garbage.
+As a consequence of its design goals, ChillDKG does not provide robustness, i.e., the protocol is not guaranteed to succeed in the presence of malicious or faulty participants.
+In fact, a single participant can cause the protocol to fail, either due to malicious intent, software bugs, or unreliable communication links.
+In such cases, users must investigate and resolve the issue before the DKG can output key material.
 
-[^no-identifiable-aborts]: When ChillDKG aborts, it is not possible to identify the misbehaving participant (unless they misbehave in certain trivial ways).
-While the ability to identify the misbehaving participant, also called *identifiable aborts*, is desirable,
-we keep this goal out of scope for simplicity.
+When ChillDKG does not terminate successfully, it is not possible to identify the misbehaving participant unless they misbehave in certain trivial ways.
+While the ability to identify the misbehaving participant, also called *identifiable aborts*, is desirable, we keep this goal out of scope for simplicity (TODO: This may change in a future version of the BIP, but no guarantee).
 
-While aborting leads to a significantly simpler protocol,
-the primary reason to abort in case of errors is that,
-we believe, trading robustness for non-exclusion is desirable in many settings:
+Adding robustness to ChillDKG would require the coordinator to exclude participants that appear unresponsive or faulty, which degrades the setup already from the beginning from `t`-of-`n` to `(t-1)`-of-`(n-1)`.
+This approach is undesirable in most scenarios, as a dishonest coordinator would have the power to exclude participants at will.
+Even if ChillDKG's design did not include a coordinator and participants had direct communication links to each other, it would be unclear how to achieve robustness with a dishonest majority.
+
+Moreover, we believe that robustness is not a desirable feature of a DKG protocol in many settings:
 For example, consider a key generation ceremony for a threshold cold wallet intended store large amounts of Bitcoin.
 If it turns out that one of the devices participating appears non-responsive, e.g., due to a loss of network or a software bug,
-it will typically be desirable to prefer security over progress, and abort instead of forcing successful termination of the ceremony.
-Note that all a robust DKG protocol could achieve is to consider that device non-responsive and effectively exclude it from the DKG session, which degrades the setup already from the beginning from `t`-of-`n` to `(t-1)`-of-`(n-1)`.
+users will typically prefer security over progress, and abort the protocol instead of forcing successful termination of the ceremony by excluding the device from the DKG session.
 While a warning can be presented to users in this case, users tend to misunderstand and ignore these.
 
 Even in distributed systems with strict liveness requirements, e.g., a system run by a large federation of nodes of which a majority is trusted, what is typically necessary for the liveness of the system is the continued ability to *produce signatures*.