diff --git a/Makefile b/Makefile
index 5f29774a1..8a014f5d8 100644
--- a/Makefile
+++ b/Makefile
@@ -26,7 +26,7 @@ CCANDIR := ccan
 
 # Where we keep the BOLT RFCs
 BOLTDIR := ../bolts/
-DEFAULT_BOLTVERSION := 5dd9d9cd5fa9bc928c0fd47602ee84b7a15822a9
+DEFAULT_BOLTVERSION := 93b7ee031b50acd59967a105f1326176a37628f9
 # Can be overridden on cmdline.
 BOLTVERSION := $(DEFAULT_BOLTVERSION)
 
diff --git a/lightningd/peer_htlcs.c b/lightningd/peer_htlcs.c
index a9af74260..215314dc3 100644
--- a/lightningd/peer_htlcs.c
+++ b/lightningd/peer_htlcs.c
@@ -564,7 +564,18 @@ static void rcvd_htlc_reply(struct subd *subd, const u8 *msg, const int *fds UNU
 	}
 
 	if (tal_count(failmsg)) {
-		/* It's our job to append the channel_update */
+		/* BOLT #4:
+		 * The `channel_update` field used to be mandatory in messages
+		 * whose `failure_code` includes the `UPDATE` flag. However,
+		 * because nodes applying an update contained in the onion to
+		 * their gossip data is a massive fingerprinting
+		 * vulnerability, the `channel_update` field is no longer
+		 * mandatory and nodes are expected to transition away from
+		 * including it. Nodes which do not provide a `channel_update`
+		 * are expected to set the `channel_update` `len` field to
+		 * zero.
+		 */
+		/* We still append the channel_update (if we have one!)  FIXME: provide an option? */
 		if (fromwire_peektype(failmsg) & UPDATE) {
 			const u8 *update = channel_update_for_error(tmpctx, hout->key.channel);
 			towire(&failmsg, update, tal_bytelen(update));
diff --git a/wire/onion_defs.h b/wire/onion_defs.h
index 6bf5f4f8f..cdfc0b3b8 100644
--- a/wire/onion_defs.h
+++ b/wire/onion_defs.h
@@ -10,7 +10,7 @@
  * * 0x8000 (BADONION): unparsable onion encrypted by sending peer
  * * 0x4000 (PERM): permanent failure (otherwise transient)
  * * 0x2000 (NODE): node failure (otherwise channel)
- * * 0x1000 (UPDATE): new channel update enclosed
+ * * 0x1000 (UPDATE): channel forwarding parameter was violated
  */
 #define BADONION	0x8000
 #define PERM		0x4000