Updated README.

README.md

@@ -15,7 +15,7 @@ Given an input CSV file reflecting the user's entire cryptocurrency transaction
 * compute gain or loss from the sale/exchange/disposal (including whether short-term or long-term)
 * record income for incoming transactions and expenses for outgoing transactions
 
-Reports (CSV file) may be exported that reflect income/expenses/gains/losses or cost basis of existing holdings.
+Reports may be exported (as CSV files) that reflect income/expenses/gains/losses or amount and cost basis of existing holdings.
 
 ---
 
@@ -46,23 +46,63 @@ The activity that gets imported **must** be in a prescribed form (a CSV file) th
 
 #### CSV file components
 
+##### Columns
+
+The first three columns (ignoring the first four rows) are for transaction metadata.
+
 * **txDate** is currently set to parse dates of the format MM/dd/YY.
 
-* **proceeds** This is the value transferred in the transaction.
+* **proceeds** This is either (a) the value transferred from one party to another in a transaction,
-For example, if one spends 0.01 BTC at a time when BTC/USD is $10,000/BTC, then the user received value of $100, therefore the proceeds of that transaction would be $100.
+or (b) the value exchanged in a trade (an exchange transaction).
-When transfering to oneself (i.e.,  not changing currencies), this value is irrelevant and ignored.
+In both cases, the value is measured in one's home currency!
+For example, if the user spends 0.01 BTC at a time when BTC/USD is $10,000/BTC,
+and in exchange for that 0.01 BTC the user receives something valued at $100,
+the proceeds of that transaction (despite it being an outflow) would be $100.
+Similarly, for the user receiving the 0.01 BTC (as an inflow), they would reflect proceeds of $100 as well.
+And if the recipient immediately spent the 0.01 BTC in exchange for XMR,
+the proceeds of that transaction would also be $100.
+Note: when transfering to oneself (i.e.,  not changing currencies), the proceeds value is irrelevant and ignored.
 This value is also ignored when the user's home currency is spent.
 
 * **memo** is useful for evaluating the final output but isn't important.
 Currently, commas in the memo are **not** supported.
 
-After three columns of transaction metadata, the *Account* columns follow.
+* *Accounts* - After three columns of transaction metadata, the *Account* columns follow.
+The increases and decreases to each account are recorded directly below in that account's column.
 
-* *Accounts* (**1**, **2**, **3**, **4**, **5**, ...): the top row reflects the account number (which currently must start at 1 and increase sequentially).
+##### Rows
-The three other values are the *name*, *ticker*, and *margin_bool*.
+
-*name* and *ticker* should be self-explanatory.
+The first four rows (ignoring the first three columns) are for account metadata.
-*margin_bool* is set usually set as 'no', 'non' (i.e., non-margin), or 'false.'
+
-To indicate a margin account, set it as 'yes', 'margin' or 'true'.
+* *Account number* (**1**, **2**, **3**, **4**, **5**, ...): the top row reflects the account number (which currently must start at 1 and increase sequentially).
+
+* *Name* is the name of the wallet or exchange.
+
+* *Ticker* should be self-explanatory (i.e., USD, EUR, BTC, XMR, ETH, LTC, etc.).
+
+* *Margin_bool* is usually set as "no", "non" (i.e., non-margin), or "false".
+To indicate a margin account, set it as "yes", "margin" or "true".
+
+* *Transactions*: After four header rows to describe the accounts, the transaction rows follow.
+Each row reflects the net effect on the accounts involved, net of any fees.
+
+For example, in the first transaction above, 0.25 BTC was received,
+but the purchase would probably really have been for, say, 0.25002.
+That 0.00002 is a transaction fee kept by the exchange, so we ignore it.
+The 0.25 represents the increase in the BTC balance, so 0.25 is used.
+
+The same logic applies to the next transaction.
+0.25 BTC was used to buy XMR, and the XMR balance increased by 180 as a result.
+But the user would have paid a transaction fee, so the amount paid for was really, say, 180.002.
+In fact, the user would literally have placed an order for 180.002 at a price where they'd pay 0.25.
+It doesn't matter, though, that the order was placed for 180.002
+because this software only cares about what you receive in your wallet as a result of the transaction.
+
+Looking at the third and fourth transactions, the same amount was withdrawn from one account and deposited into another account.
+This is an unrealistic scenario because network transaction fees and exchange transfer fees are ignored.
+There are exchanges who will cover the transfer fee, but it's rare.
+And it certainly is unrealistic for the user to send from their personal wallet (in the fourth transaction) with no network fee.
+These transactions are oversimplified on purpose.
 
 ###### Margin accounts
 
@@ -72,8 +112,9 @@ The quote account is the market.
 The quote account's ticker requires a different formatting.
 For example, when using BTC to long XMR, the BTC account must be reflected with the ticker BTC_xmr.
 
-* Margin gain or loss is accounted for when there is activity in the 'spot' account.
+* Margin gain or loss is accounted for when there is activity in the related "spot" account.
 For example, you won't reflect a loss until you actually spend your holdings to pay off your loans.
+Until you sell, it's simply an unrealized loss.
 
 ---
 
@@ -105,7 +146,8 @@ Run `./target/debug/cryptools-rs` with no arguments (or `--help`, or `-h`) to se
 Alternatively, run `cargo run`, in which case command-line arguments for `cryptools-rs` may be entered following `--`, e.g., `cargo run -- -h`.
 
 Running with no arguments will lead the user through a wizard, or all required arguments can be passed as command-line flags/options/args.
-See `/examples/` directory for further guidance.
+See `/examples/` directory for further guidance,
+or jump directly to the [examples.md](https://github.com/scoobybejesus/cryptools-rs/blob/master/examples/examples.md) file.
 
 ## Development state