Tidy docs

docs/ANN.md

@@ -1,48 +0,0 @@
-# Announcement
-
-## Advantages vs dcrstakepool
-
-### For VSP Administrators
-
-- An instance of bbolt db on the front-end server is used as the single source
-  of truth:
-  - bbolt does not have the sys admin overhead associated with maintaining a
-      MySQL database. The database will be automatically created and maintained
-      by vspd.
-  - The bbolt database is only accessed by vspd. There is no need to open
-      additional ports on your front-end server for the voting wallets to access
-      the database.
-- Voting wallet servers require only dcrwallet and dcrd. There is no longer a
-  VSP binary (ie. stakepoold) running on voting servers.
-- Voting servers no longer need dcrd to be running with `--txindex`.
-- No need to use the same wallet seed on each voting wallet.
-- A new fee address and amount are requested for each ticket:
-  - Fee addresses are never reused.
-  - Fee amount can be changed freely.
-- No emails or personal information are held. No need to worry about GDPR et al.
-
-### For VSP Users
-
-- No redeem script to back up.
-- No registration required - no email, no password, no CAPTCHA.
-- Voting preferences can be set for each individual ticket.
-- No address reuse.
-- VSP fees are paid independently of the ticket purchase, rather than being
-  included in the ticket:
-  - Multiple VSPs can be used for a single ticket.
-  - Fees can be paid using funds from a mixed account.
-  - VSP users can purchase tickets in the same anonymity set at solo stakers.
-
-### For the Decred Ecosystem
-
-- Solo tickets and VSP tickets are indistinguishable on-chain.
-- Clients and servers can hold eachother accountable for actions. This enables
-  users to prove if a VSP is misbehaving, and VSPs to defend themselves if they
-  are falsely accused.
-
-## Disadvantages
-
-- Front-end is more important than before.
-- Front-end requires dcrd with `--txindex`.
-- Failure cases
-  - fee tx doesnt broadcast

docs/api.md

@@ -5,7 +5,7 @@
 - Success responses use HTTP status 200 and a JSON encoded body.
 
 - Error responses use either HTTP status 500 or 400, and a JSON encoded error
-  in the body. For example `{"error":"Description"}`.
+  in the body, e.g. `{"error":"Description"}`.
 
 - Requests which reference specific tickets need to be properly signed as
   described in [two-way-accountability.md](./two-way-accountability.md).
@@ -18,7 +18,7 @@
 ### Get VSP info
 
 Clients should retrieve the VSP's public key so they can check the signature on
-future API responses. A VSP should never change their public key so it can be
+future API responses. A VSP should never change their public key, so it can be
 requested once and cached indefinitely. `vspclosed` indicates that the VSP is
 not currently accepting new tickets. Calling `/feeaddress` when a VSP is closed
 will result in an error.
@@ -44,8 +44,11 @@ will result in an error.
 **Registering a ticket is a two step process. The VSP will not add a ticket to
 its voting wallets unless both of these calls have succeeded.**
 
+#### Step One
+
 Request fee amount and address for a ticket. The fee amount is only valid until
-the expiration time has passed.
+the expiration time has passed. The fee amount is an absolute value measured in
+DCR.
 
 - `POST /feeaddress`
 
@@ -65,12 +68,14 @@ the expiration time has passed.
     {
         "timestamp":1590509066,
         "feeaddress":"Tsfkn6k9AoYgVZRV6ZzcgmuVSgCdJQt9JY2",
-        "fee":0.001,
+        "feeamount":0.001,
         "expiration":1590563759,
         "request": {"<Copy of request body>"}
     }
     ```
 
+#### Step Two
+
 Provide the voting key for the ticket, voting preference, and a signed
 transaction which pays the fee to the specified address. If the fee has expired,
 this call will return an error and the client will need to request a new fee by
@@ -117,10 +122,9 @@ fields:
 - `feetxbroadcast` is true when the VSP has broadcast the fee transaction.
 - `feeconfirmed` is true when the fee transaction has 6 confirmations.
 
-`feetxhash` will only be populated if `feetxbroadcast` is true.
-
 The VSP will only add tickets to the voting wallets when all four of these
-conditions are met.
+conditions are met. `feetxhash` will only be populated if `feetxbroadcast` is
+true.
 
 - `GET /ticketstatus`
 

docs/two-way-accountability.md

@@ -12,4 +12,8 @@
 
 ### Server does not vote ticket
 
+TODO
+
 ### Client denies changing their voting preferences
+
+TODO