WIP explain blame interface

Author: real-or-random

README.md

@@ -135,6 +135,7 @@ In summary, we aim for the following design goals:
  - **Broad applicability**:  ChillDKG supports a wide range of scenarios, from those where the signing devices are owned and connected by a single individual to those where multiple owners manage the devices from distinct locations.
  - **Simple backups**: ChillDKG allows recovering the DKG output using the host secret key and common recovery data shared among all participants and the coordinator. This eliminates the need for session-specific backups, simplifying 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.
+ - **Blaming functionality**: If a ChillDKG session aborts, it is possible to identify and blame a single party responsible for the failure (assuming the network, and, depending on the circumstances, the coordinator, is reliable).
  - **Per-participant public keys**: When ChillDKG is used with FROST, partial signature verification is supported.
  - **Taproot-safe threshold public key**: ChillDKG prevents malicious participants from embedding a hidden [[BIP 341]](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki) Taproot commitment to a script path in the threshold public key.
 
@@ -144,14 +145,13 @@ and due to its low overhead, we recommend ChillDKG even if secure communication
 
 #### Why Robustness is Not a Goal
 
-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.
+If a ChillDKG session fails due to the participants or the coordinator deviating from the protocol,
+any aborting party will be able to identify and blame a single party responsible for the failure (assuming the network, and, depending on the circumstances, the coordinator, is reliable).
+
+However, ChillDKG does not provide full robustness, i.e., the protocol is not designed to succeed in the presence of 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.
 
-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 there is no guarantee.)
-
 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 malicious coordinator would have the power to exclude participants at will,
 and 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 in a dishonest majority setting.
@@ -467,6 +467,9 @@ Each participant has a point-to-point communication link to the *coordinator*
 
 If there is no dedicated coordinator, one of the participants can act as the coordinator.
 
+Each participant and the coordinator, and the communication links may either be *honest*, i.e., reliable and adhering to the protocol, or *faulty*, i.e., controlled by an attacker or unreliable (e.g., due to software bugs).
+
+#### DKG Security
 ### Inputs and Output
 
 The inputs of a session consist of a long-term *host secret key* (individual to each participant, not provided by the coordinator) and public *session parameters* (common to all participants and the coordinator).
@@ -515,7 +518,7 @@ and we believe that a general recommendation is not useful.
 ### Recovering Stuck Participants
 
 The mere fact that the coordinator or a participant deems a ChillDKG session successful does not imply that other participants deem it successful yet.
-Indeed, due to failing network links or invalid messages sent by malicious participants,
+Indeed, due to failing communication links or invalid messages sent by malicious participants,
 it is possible that a party has deemed the DKG session successful, but others have not (yet) and thus are stuck in the DKG session.
 In that case, the successful parties can eventually convince the stuck participants to consider the DKG session successful by presenting the recovery data to them.
 The recovery data can, e.g., be attached to the first request to initiate a FROST signing session.
@@ -553,18 +556,34 @@ e.g., stop sending additional funds to addresses derived from it.
 it will still be possible to spend the funds,
 and even recovered participants can participate in signing sessions.)
 
+### Blaming Functionality
+
+Any faulty party can make a ChillDKG session abort by sending a message that deviates from the protocol specification.
+To help investigating and resolving these protocol failures, ChillDKG provides *optional blaming functionality* that enables honest protocol parties
+to identify and blame at least one participant suspected to be faulty:[^missing-messages]
+ 1. If an honest participant aborts the session, then this participant will blame at least one participant or the coordinator.
+ 2. If an honest coordinator aborts the session, then the coordinator then will blame at least one participant.
+
+[^missing-messages]: Moreover, if a session is stuck due to missing messages, the receiving party will (trivially) know who has not sent their protocol messages (yet).
+
+The aborting party will be guaranteed that the suspected party is indeed faulty
+*only if* all messages in the ChillDKG session have been transmitted correctly over the communication links, and, in case of a participant blaming another participant, if the coordinator is additionally honest.
+
+It is important to understand that this is a conditional statement.
+For example, assume that the condition of a honest coordinator is violated.
+In that case, even if all participants are honest, the malicious coordinator can deviate from the protocol in a way that makes one participant blame another participant, when, in fact, it is the coordinator who is faulty and not the suspected participant.
+
+
 ### Threat Model and Security Goals
 
-Some participants, the coordinator, and all network links may be malicious, i.e., controlled by an attacker.
 We expect ChillDKG to provide the following informal security goals when it is used to set up keys for the FROST threshold signature scheme.
-
 If a participant deems a protocol session successful (see above), then this participant is assured that:
- - A coalition of at most `t - 1` malicious participants and a malicious coordinator cannot forge a signature under the returned threshold public key on any message `m` for which no signing session with at least one honest participant was initiated. (Unforgeability)[^unforgeability-formal]
- - All honest participants who deem the protocol session successful will have correct and consistent protocol outputs.
+ 1. A coalition of at most `t - 1` faulty participants and a faulty coordinator cannot forge a signature under the returned threshold public key on any message `m` for which no signing session with at least one honest participant was initiated. (Unforgeability)[^unforgeability-formal]
+ 2. All honest participants who deem the protocol session successful will have correct and consistent protocol outputs.
    In particular, they agree on the threshold public key, the list of public shares, and the recovery data.
    Moreover, any `t` of them have secret shares consistent with the threshold public key.[^correctness-formal]
    This means that any `t` participants have all the necessary inputs to run FROST signing sessions which produce signatures valid under the threshold public key.
- - The success certificate will, when presented to any other (honest) participant, convince that other participant to deem the protocol successful.
+ 3. The success certificate will, when presented to any other (honest) participant, convince that other participant to deem the protocol successful.
 
 [^unforgeability-formal]: See Chu, Gerhart, Ruffing, and Schröder [Definition 3, [CGRS23](https://eprint.iacr.org/2023/899)] for a formal definition.