nopara73

> Finally, I think the connection confirmation phase can just be omitted since final ack does not provide any new information using the unified protocol, output registration could just conclude...

> also i don't think we should list SumProof here, unless we also want to break down everything else (initial credentials, and for each registration including inputs, the list of...

> Why it cannot be omitted is because if someone doesn't confirm connection then he has to be marked malicous, otherwise it'd be a DoS attack. Also with your previous...

I incorporated your ideas. ``` @startuml title Scenario: A Participant Is Consolidating 2 Coins (Alice1, Alice2) Into 1 (Bob)\n == Input Registration == Satoshis -> Coordinator : GetCoinjoinStatuses Satoshis Coordinator...

# Today's Progress (2020-06-18) ``` @startuml title Scenario: A Participant Is Consolidating 2 Coins (Alice1, Alice2) Into 1 (Bob)\n == Input Registration == Satoshis -> Coordinator : GetCoinjoinStatuses Satoshis Coordinator...

> i don't understand why the same alice has to request zero credentials more than once (i believe you discussed that after i had to leave the call?) Zero credentials...

> also note that output registrations as specified in the unified protocol also require credential requests and issuance, i think this can be omitted depending on how output amounts are...

> also i believe the 4th interaction during input registration is meant to be for alice2, not alice1? No, this is how I'm depicting the fact that Alice doesn't know...

I added the Alice3 idea. ``` @startuml title Scenario: A Participant Is Consolidating 3 Coins (Alice1, Alice2, Alice3) Into 1 (Bob)\n == Input Registration == Satoshis -> Coordinator : GetCoinjoinStatuses...

> ZeroCredentials and RealCredentials should just be Credentials, and RealCredentialRequests should be CredentialRequests but ZeroCredentialRequest should stay that way because it has a different structure I won't incorporate that, because...