The Protocol

[nopara73]

[Obsolated] See https://github.com/zkSNACKs/WabiSabi/blob/master/protocol.md

[nothingmuch]

something that is not clear to me about the state diagram and confirmation: suppose that a round fails, and a restricted round is attempted, and connection confirmation times out without reaching a minimum... should the inputs that did register and confirm be treated differently than the inputs who did not? without a signing phase there is no way to assign blame, but a signing phase may be detrimental for privacy. a malicious user intending to deny service still gets at least one input blamed in that case, since it only applies to retried rounds

[nopara73]

Input Registration

• failing to connection-confirm within alice timeout -> NO punushment
• failing to connection-confirm within phase timeout -> NO punushment
• deregister -> NO punushment

Connection Confirmation

• failing to connection-confirm within alice timeout -> NO punushment
• failing to connection-confirm within phase timeout -> YES punushment
• deregister -> refuse

[nopara73]

What is returned for the status request?

Understanding the protocol without knowing what's in CoinJoinStatuses[], based on just the interaction diagram is not possible. This comment clarifies it.

Array

Every element in the CoinJoinStatuses[] array is a status of a currently running round.

Element

The structure of an element in the returned array is the following:

• Phase
• RoundId
• Timeout
• BlameOf // If it's a blame round, then it is the RoundId of the parent round.
• PhaseStatus // What else the response contains depends on the current phase.

PhaseStatus in InputRegistration

• CredentialIssuerParameters
• RegisteredInputCount
• MaxRegisteredInputCount
• FeeRate

CoordinatorParameters

For input registration the user submits a CoordParamSig, which is a signature on the hash of the CoordinatorParameters. It is used to prove ownership of an input, but also to ensure every other participant in the round got the same CoordinatorParameters, thus the server cannot fingerprint them by giving out different parameters to different users. CoordinatorParameters includes RoundId, BlameOf, CredentialIssuerParameters and FeeRate.

PhaseStatus in ConnectionConfirmation

• ConfirmedInputCount
• MaxConfirmedInputCount

PhaseStatus in OutputRegistration

• RegisteredOutputCount
• RegisteredOutputVolume
• TotalInputVolume

PhaseStatus in TransactionSigning

• SignedInputCount
• MaxSignedInputCount
• EncryptedUnsignedCoinJoin
• InputRoundParameterSignatures

PhaseStatus in TransactionBroadcasting

• CoinJoin