Minor doc reword (#11)

Author: Ruteri

README.md

@@ -9,7 +9,7 @@ For an overview of the protocol, see [protocol/protocol.md](protocol/protocol.md
 
 > [!WARNING]
 > This repository is a work in progress. A lot of it is vibe-coded, a lof of the cryptography is hand-rolled. Do not use for any production use cases!
-> Do use this repository if you want to familiarize yourself with DCNet/ZIPNet and/or experiment with the protocol 💖
+> Do use this repository if you want to familiarize yourself and/or experiment with the protocol 💖
 
 ## Overview
 

protocol/protocol.md

@@ -1,10 +1,10 @@
 # Auction-based DCNet
 
-The ADCNet protocol is heavily inspired by [ZIPNet: Low-bandwidth anonymous broadcast from (dis)Trusted Execution Environments](https://eprint.iacr.org/2024/1227). This document is a brief introduction to ZIPNet and a protocol-level description of auction-based scheduling and variable-size messaging that improves ZIPNet's scheduling for use cases where optimal utility-based allocation of bandwidth is needed.
+The ADCNet protocol is heavily inspired by [ZIPNet: Low-bandwidth anonymous broadcast from (dis)Trusted Execution Environments](https://eprint.iacr.org/2024/1227). This document is a brief introduction to ZIPNet and a protocol-level description of auction-based scheduling and variable-size messaging that improves ZIPNet's scheduling for use cases where optimal utility-based allocation of bandwidth warrants a slight increase in the cost of scheduling messages.
 
 ### ZIPNet overview
 
-ZIPNet, as most DC nets, is run by a set of Clients and Servers. Clients attempt to send messages anonymously ("talking") and in addition provide "cover traffic", network traffic that hides where the actual messages originate. The set of "talking" Clients and Clients sending "cover traffic" makes up the anonymity set — the aim is for any realistic adversary to not be able to distinguish the actual origin of any message better than chance within the anonymity set. Clients encrypt ("blind") their messages to some set of Servers, which then collaboratively decrypt ("unblind") the messages, revealing the content. ZIPNet in addition introduces Aggregators, a middle layer that lessens network bandwidth requirements for Servers by aggregating large subsets of Client messages into a single message which is forwarded to the Servers.  
+ZIPNet is run by a set of Clients and Servers. Clients attempt to send messages anonymously ("talking") and in addition provide "cover traffic", network traffic that hides where the actual messages originate. The set of "talking" Clients and Clients sending "cover traffic" makes up the anonymity set — the aim is for any realistic adversary to not be able to distinguish the actual origin of any message better than chance within the anonymity set. Clients encrypt ("blind") their messages to some set of Servers, which then collaboratively decrypt ("unblind") the messages, revealing the content. ZIPNet in addition introduces Aggregators, a middle layer that lessens network bandwidth requirements for Servers by aggregating large subsets of Client messages into a single message which is forwarded to the Servers.  
 
 The protocol consists of two rounds: scheduling and messaging. For simplicity the scheduling is piggy-backing on messaging, which results in a single round consisting of a single message containing both the message for the current round, and the scheduling for the upcoming round.  
 
@@ -51,7 +51,7 @@ sequenceDiagram
 ### ZIPNet protocol key details
 
 **Scheduling in ZIPNet**  
-As in other DCNet constructions, Clients can only send messages in preallocated slots. In ZIPNet, which this protocol is mostly based, scheduling is done by inserting a message fingerprints into a (large) scheduling bitvector. Each Client which wants to "talk" inserts their fingerprint at a pseudorandom location derived from their identity, blinds the scheduling vector with pairwise-shared secrets exchanged previously with Servers, and sends the resulting blinded vector to an Aggregator. Aggregators XOR all the scheduling vectors and forward the result to Servers for unblinding. When the scheduling vector is revealed, Clients check if their fingerprint appears unmodified in the revealed aggregate scheduling vector, if so they know they will not have conflicts with any other Clients and they map the position in the scheduling vector to a position in the message vector for the upcoming round.  
+In ZIPNet, Clients can only send messages in preallocated slots. Scheduling is done by inserting a message fingerprints into a (large) scheduling bitvector. Each Client which wants to "talk" inserts their fingerprint at a pseudorandom location derived from their identity, blinds the scheduling vector with pairwise-shared secrets exchanged previously with Servers, and sends the resulting blinded vector to an Aggregator. Aggregators XOR all the scheduling vectors and forward the result to Servers for unblinding. When the scheduling vector is revealed, Clients check if their fingerprint appears unmodified in the revealed aggregate scheduling vector, if so they know they will not have conflicts with any other Clients and they map the position in the scheduling vector to a position in the message vector for the upcoming round.  
 
 **Messaging in ZIPNet**  
 Once the scheduling vector from the previous round is revealed, each Client knows whether it was allocated a message slot. If so, it simply inserts the message at the location dictated by a linear mapping of the scheduling vector to the message vector. The message vector is then blinded and sent to an Aggregator. Once an Aggregator has received enough of those messages for a big enough anonymity set, it XOR-s all of the messages together and forwards either to a hgher-level Aggregator or to Servers. Servers submit aggregated unblinding vectors to the round's leader which then reveals the message vector, which concludes the round.