--- a/README.md	Sat Oct 08 00:10:30 2016 +0200
+++ b/README.md	Sat Oct 08 00:38:17 2016 +0200
@@ -11,39 +11,44 @@
 
 ### Bootstrapping
 
-* A set of participants is started. Participant `A`'s `ConsensusServer` receives a StartParticipation request.
-  This request is `StartParticipation(0, 0, Member{addr: "A"}, [Member{addr: "A"}], []byte{})` (i.e., an empty
-  StartParticipation request)
-* Now one participant is running, and sees that it itself is the master. It now finds out in some way which other
-  participants to add, and calls `AddMember()` on itself. The library will arrange a process by which a new member
-  is added to the consensus round.
-* Repeat this for other members
+* A set of participants is started. 
+* On the participant that has been selected to become the first master, `InitMaster()` is called.
+* After `InitMaster()`, `AddParticipants()` adds more participants to the cluster. The list of participants
+  could for example come from a configuration file or command line flags.
+* Then, the cluster should be up and running. Now, on any participant, `Submit()` can be called to submit
+  changes to the state machine. Those changes are replicated through the master. (see next section)
 
 ### Normal operation
 
 We assume that the current instance is 12, and the sequence number in that instance is 34.
 
 * One participant wants to modify the state. It calls `Submit()` on the `Participant` with one or more changes.
-* If the Participant is not master, it will send the request to the master using the `Submit()` method on the stub.
-* If the Participant is the master, or has received a `Submit` request, it will proceed by coordinating the change.
+    * If the Participant is not master, it will send the request to the master using the `Submit()` method on the stub.
+    * If the Participant is the master, or has received a `Submit` request, it will proceed by coordinating the change.
 * First, all non-master participants are sent `Accept(12, 35, []Change{ *some change* })`.
-* This leads to the non-master participants *staging* that change.
-* The next time the master wants to apply a change, it sends `Accept(12, 36, []Change{ *some new change* })`. This leads
-  to non-master participants "committing" (i.e. applying) all staged changes before sequence `36` to the state machine.
+    * The request is sent using the `ConsensusClient` stub that was returned by the `ClientFactory` implementation.
+* This leads to the non-master participants *staging* that change into a special area. The change is not yet applied to the state machine.
+* The next time the master wants to apply another change, it sends `Accept(12, 36, []Change{ *some new change* })`. This leads
+  to non-master participants "committing" (i.e. applying) all staged changes before sequence `36` to the state machine, including
+  our change `35` from before.
 
 ### Master has crashed
 
-Current instance: 22 Current sequence: 44
+Current instance: 22; Current sequence: 44
 
 * A participant, "B", wants to modify the state, but can't reach the master to `Submit()` a change. It proceeds by
   becoming a candidate. It sends `Prepare(23, Member{ addr: "B" })` to all known members. If a majority replies within
-  the deadline with a positive vote, then the `B` is the new master.
+  the deadline with a positive vote, then `B` is the new master.
 * In order for all participants to know about this change, `B` submits a request `Accept(23, 1, []Change{})` which confirms
-  the previous `Prepare()` call (because of the new instance in the `Accept` request)
-* Now everyone knows of the new master, and the cluster continues in *Normal operation*.
+  the previous `Prepare()` call, and makes all non-master participants acknowledge the new master.
+* Now everyone knows of the new master, and the cluster continues as in *Normal operation*.
 
 ### Adding/removing members
 
 * Membership changes are relatively straight-forward; they are just special changes that don't use `Accept()`, but rather
   the `AddMember()` and `RemoveMember()` methods in `ParticipantStub`.
-
+* Membership changes are staged the same way as normal changes; memberships only actually change once a membership change
+  has been committed by an `Accept()` call with a higher sequence number.
+* Membership adds are communicated to all old members. After successfully staging the change (i.e., getting a majority vote),
+  the new member is started using `StartParticipation()`.
+* Membership removals are communicated to all members, including the one to be removed. Upon