diff --git a/doc/spec/proposals/000-index.txt b/doc/spec/proposals/000-index.txt
index d75157650d..dd91efeccd 100644
--- a/doc/spec/proposals/000-index.txt
+++ b/doc/spec/proposals/000-index.txt
@@ -82,6 +82,7 @@ Proposals by number:
 157  Make certificate downloads specific [ACCEPTED]
 158  Clients download consensus + microdescriptors [OPEN]
 159  Exit Scanning [OPEN]
+160  Authorities vote for bandwidth offsets in consensus [OPEN]
 
 
 Proposals by status:
@@ -103,6 +104,7 @@ Proposals by status:
    156  Tracking blocked ports on the client side [for 0.2.?]
    158  Clients download consensus + microdescriptors
    159  Exit Scanning
+   160  Authorities vote for bandwidth offsets in consensus [for 0.2.2.x]
  ACCEPTED:
    110  Avoiding infinite length circuits [for 0.2.1.x] [in 0.2.1.3-alpha]
    117  IPv6 exits [for 0.2.1.x]
diff --git a/doc/spec/proposals/160-bandwidth-offset.txt b/doc/spec/proposals/160-bandwidth-offset.txt
new file mode 100644
index 0000000000..078754b771
--- /dev/null
+++ b/doc/spec/proposals/160-bandwidth-offset.txt
@@ -0,0 +1,80 @@
+Filename: 160-bandwidth-offset.txt
+Title: Authorities vote for bandwidth offsets in consensus
+Version: $Revision$
+Last-Modified: $Date$
+Author: Roger Dingledine
+Created: 4-May-2009
+Status: Open
+Target: 0.2.2.x
+
+1. Motivation
+
+  As part of proposal 141, we moved the bandwidth value for each relay
+  into the consensus. Now clients can know how they should load balance
+  even before they've fetched the corresponding relay descriptors.
+
+  Putting the bandwidth in the consensus also lets the directory
+  authorities choose more accurate numbers to advertise, if we come up
+  with a better algorithm for deciding weightings.
+
+  Our original plan was to teach directory authorities how to measure
+  bandwidth themselves; then every authority would vote for the bandwidth
+  it prefers, and we'd take the median of votes as usual.
+
+  The problem comes when we have 7 authorities, and only a few of them
+  have smarter bandwidth allocation algorithms. So long as the majority
+  of them are voting for the number in the relay descriptor, the minority
+  that have better numbers will be ignored.
+
+2. Options
+
+  One fix would be to demand that every authority also run the
+  new bandwidth measurement algorithms: in that case, part of the
+  responsibility of being an authority operator is that you need to run
+  this code too. But in practice we can't really require all current
+  authority operators to do that; and if we want to expand the set of
+  authority operators even further, it will become even more impractical.
+  Also, bandwidth testing adds load to the network, so we don't really
+  want to require that the number of concurrent bandwidth tests match
+  the number of authorities we have.
+
+  The better fix is to allow certain authorities to specify that they are
+  voting on bandwidth "offsets": how much they think the weight should
+  be changed for the relay in question. We should put the offset vote in
+  the stanza for the relay in question, so a given authority can choose
+  which relays to express preferences for and which not.
+
+3. Security implications
+
+  If only some authorities choose to vote on an offset, then a majority of
+  those voting authorities can arbitrarily change the bandwidth weighting
+  for the relay. At the extreme, if there's only one offset-voting
+  authority, then that authority can dictate which relays clients will
+  find attractive.
+
+  This problem isn't entirely new: we already have the worry wrt
+  the subset of authorities that vote for BadExit.
+
+  To make it not so bad, we should deploy at least three offset-voting
+  authorities.
+
+  Also, authorities that know how to vote for offsets should vote for
+  an offset of zero for new nodes, rather than choosing not to vote on
+  any offset in those cases.
+
+4. Design
+
+  First, we need a new consensus method to support this new calculation.
+
+  Now v3 votes can have a new weight on the "w" line:
+    "Bandwidth_Offset=" INT.
+  Once we're using the new consensus method, the new way to compute the
+  Bandwidth weight is by taking the old vote (explained in proposal 141:
+  median, then choose the lower number in the case of ties), and adding
+  or subtracting the median offset (using the offset closer to 0 in the
+  case of ties, and with a sum of 0 if the sum is negative).
+
+  Then the actual consensus looks just the same as it did before,
+  so clients never have to know that this additional calculation is
+  happening.
+