Update atomic_transfer.md

docs/atomic_transfer.md

@@ -2,21 +2,21 @@
 
 ## Multiple statecoins atomic transfer
 
-The purpose of the atomic transfer protocol is to enable two (or more) transfers to be completed in a way that they all complete or none of them do. This effectively means that the transfer-receiver function and key update is only completed if both receivers have the correct information to proceed. Once each receiver has verified that the transfer message they have received is valid, then the other parties can be allowed to complete transfer-receiver. 
+The purpose of the atomic transfer protocol is to enable two (or more) coin transfers to be completed in a way that they all complete or none of them do. This effectively means that the transfer-receiver function and key update is only completed if both receivers have the correct information to proceed. Once each receiver has verified that the transfer message they have received is valid, then the other parties can be allowed to complete transfer-receiver. 
 
-To enable this there needs to be a mechanism to prevent the transfer-receiver being completed before the other parties have verified their transfer messages. If all parties verify, then transfer-receiver can proceed, otherwise the key shares are not updated and ownership of the coins remains with the inital owner. 
+To enable this there needs to be a mechanism to prevent the transfer-receiver being completed before the other parties have verified and confirmed their transfer messages. If all parties verify, then transfer-receiver can proceed, otherwise the key shares are not updated and ownership of the coins remains with the inital owner. 
 
 The process is performed by each party in the atomic transfer supplying a `batch_id` in the transfer-sender message. The use of this (as opposed to leaving this null) is that the statecoin is put into a special *locked* state for a configured timeout period after the first `batch_id` is submitted. During this locked status two things are prevented 1) The sender cannot perform another `/transfer/sender` operation on the same coin (i.e. to send to a different address) and 2) `/transfer/receiver` cannot be performed until all coins with the same `batch_id` are *unlocked* by all the owners unlocking the coins with a new `/transfer/unlock` function. At the end of the timeout (if all coins with a specified `batch_id` have not been unlocked), the `/transfer/receiver` function will still be blocked (i.e. return error) but the original owner can repeat `/transfer/sender` again with a null `batch_id` to regain control of the coin. 
 
 ### Protocol
 
-The statecoin DB table will have 3 additional columns: `batch_id` (string), `batch-time` (integer) and `locked` (boolen). By default `batch_id`, `batch-time` are null and `locked` is `false`. The server is configured with `batch-timeout` parameter in seconds (in practice this will be some number of minutes). 
+The `statechain_transfer` DB table can have 3 additional columns: `batch_id` (string), `batch-time` (integer) and `locked` (boolen). By default `batch_id`, `batch-time` are null and `locked` is `false`. The server is configured with `batch-timeout` parameter in seconds (in practice this will be some number of minutes). 
 
 The atomic transfer will then proceed as follows:
 
-1. The two parties that want to engage in an atomic transfer cooperate and share a `batch_id` (this is just a random UUID generated by one of the participants and shared with the other). 
-2. The two parties swap `sc` addresses that they want the other coin paid to. 
-3. They each perform `/transfer/sender {statechain_id, batch_id, auth_sig, new_user_auth_key}` with the `batch_id` paying to the other party `new_user_auth_key` and then create and upload the transfer message. 
+1. The two or more parties that want to engage in an atomic transfer cooperate and share a `batch_id` (this is just a random UUID generated by one of the participants and shared with the other). One party can generate it and share with the others. 
+2. The parties each generate a `ml1` address that they want the coin they will recieve paid to and send to the sender.  
+3. Each party performs `/transfer/sender {statechain_id, batch_id, auth_sig, new_user_auth_key}` with the `batch_id` paying to the other party `new_user_auth_key` and then create and upload the transfer message. 
 4. If the `batch_id` is set in `/transfer/sender` (and not null) the server adds this to the `batch_id` DB column for the `statechain_id` and updates the `locked` status to `true`. 
 5. The server then checks all other statecoins to see if the same `batch_id` is used for any other coin (DB query). 
 If there are no other coins with this `batch_id`, then it adds the current time (unix epoch time in seconds) to the `batch-time` column.