diff --git a/www.i2p2/pages/bittorrent.html b/www.i2p2/pages/bittorrent.html
index 0c8eeb2c9017daf28c7a3f23ec68786d2d944923..53cb640fc315d390a4c0596ef4c632b4a9170a36 100644
--- a/www.i2p2/pages/bittorrent.html
+++ b/www.i2p2/pages/bittorrent.html
@@ -1,7 +1,7 @@
 {% extends "_layout.html" %}
 {% block title %}Bittorrent over I2P{% endblock %}
 {% block content %}
-Updated May 2012, current as of router version 0.9
+Updated August 2012, current as of router version 0.9.1
 
 
 <p>There are several bittorrent clients and trackers on I2P.
@@ -220,7 +220,7 @@ Queries use I2CP protocol number 17.
 In addition to that UDP port, we use a second datagram
 port equal to the query port + 1. This is used to receive
 unsigned (raw) datagrams for replies, errors, and announces.
-This port provides increased efficiency sine replies
+This port provides increased efficiency since replies
 contain tokens sent in the query, and need not be signed.
 We call this the "response port".
 This is the "rport" value from the extension message.
@@ -239,6 +239,12 @@ In a response, the "nodes" key is a
 single byte string with concatenated compact node info.
 </p>
 <p>
+Secure node ID requirement: To make various DHT attacks more difficult,
+the first 4 bytes of the Node ID must match the first 4 bytes of the destination Hash,
+and the next two bytes of the Node ID must match the next two bytes of the
+destination hash exclusive-ORed with the port.
+</p>
+<p>
 In a torrent file,
 the trackerless torrent dictionary "nodes" key is TBD.
 It could be a list of