Give SIP number 9

README.md

@@ -21,4 +21,5 @@ Index
 | [0006](sip-0006.md)      | Farmer Load Balancing Based on Reputation | Moby von Briesen | Standard | Draft |
 | [0007](sip-0007.md)      | Storj Bridge Directory with an Ethereum Contract | Braydon Fuller  | Standard | Draft |
 | [0008](sip-0008.md)      | Farmer Time-locked Storage Payouts | Braydon Fuller  | Standard | Draft |
+| [0009](sip-0009.md)      | Bandwidth Reputation and Accounting | Braydon Fuller  | Standard | Draft |
 | [0032](sip-0032.md)      | Hierarchically Deterministic Node IDs     | Braydon Fuller  | Standard | Active |

sip-bandwidth.md → sip-0009.md

@@ -1,5 +1,5 @@
 ```
-SIP: ?
+SIP: 9
 Title: Bandwidth Reputation and Accounting
 Author: Braydon Fuller <[email protected]>
 Status: Draft
@@ -26,7 +26,7 @@ There are three perspectives for each shard transfer; the Client, Bridge and Far
 - The Client will then send an *Exchange Report* on the SUCCESS or FAILURE of that transfer. Each report MUST match with a corresponding *Storage Event*, otherwise it should be ignored.
 - A report from the Farmer can help confirm failure on the Client. However accurate reporting shouldn't be expected. As we can see by taking a look at the possible combinations and how the discrepancies can be resolved, and that the most relevant data is from the Client:
 
-![Resolving discrepancies in perspectives](sip-bandwidth/exchange-reports.png)
+![Resolving discrepancies in perspectives](sip-0009/reports.png)
 
 A Client report of a FAILURE or otherwise UNKNOWN will be handled with special consideration for the purpose to encourage it's only used when there is actual FAILURE.
 - There will be a limited percentage of unconfirmed FAILURE reports to total reports that can be made — there should only be a small part of the network that isn't cooperating.
@@ -80,7 +80,7 @@ A report from a Farmer MUST be signed to authenticate it, the signature should f
 
 ### Reputation
 
-A periodic script can query *Storage Events* between two points in time and apply those results to a bandwidth reputation metric on a contact. This could be based on a rolling window or estimated moving average as similar to `timeoutRate` and `responseTime` currently on a contact. 
+A periodic script can query *Storage Events* between two points in time and apply those results to a bandwidth reputation metric on a contact. This could be based on a rolling window or estimated moving average as similar to `timeoutRate` and `responseTime` currently on a contact.
 
 Reference Implementation
 ------------------------