docs: Update tutorial 6

docs/src/tutorials/tutorial-6.md

@@ -12,13 +12,12 @@ Why should you care? UX.
 
 Consider a wallet. Would you rather have a wallet with a single SOL address, which you
 can use to receive *all* SPL tokens, or would you rather have a wallet with a different
-address for every SPL token. Now generalize this. For everyone program you use, do you
+address for every SPL token. Now generalize this. For every program you use, do you
 want a single account, i.e. your SOL wallet, to define your application state? Or do
-you want to keep track of all your account addresses for every program in existance?
+you want to keep track of all your account addresses, separately, for every program in existance?
 
-Associated accounts allow you to easily calculate addresses, and thus find,
-accounts for any program of any type. A huge improvement on the account model introduced
-thus far.
+Associated accounts allow your users to reason about single address, their main SOL wallet,
+a huge improvement on the account model introduced thus far.
 
 Luckily, Anchor provides the ability to easily created associated program accounts for your program.
 
@@ -69,6 +68,18 @@ This can be used, for example, to create multiple different associated accounts,
 which is associated *with* a new piece of metadata. In the token program, these pieces
 of metadata are mints, i.e., different token types.
 
+Lastly, notice the two accounts at the bottom of account context.
+
+```rust
+    rent: Sysvar<'info, Rent>,
+    system_program: AccountInfo<'info>,
+```
+
+Although a bit of an implementaion detail, these accounts are required so that Anchor
+can create your associated account. By convention, the names must be as given here.
+
+For more details on how to use `#[account(associated)]`, see [docs.rs](https://docs.rs/anchor-lang/latest/anchor_lang/derive.Accounts.html).
+
 ## Using the Client
 
 The client can be used similarly to all other examples. Additionally, we introduce