fix: refuse an unsigned handshake challenge

Every node the 4.0 floor admits signs its challenge, and one without a
channel binding could not complete the proof anyway, so a missing
signature is refused like a wrong one (browser and QUIC client).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

2 files changed, 9 insertions, 10 deletions

diff --git a/docs/MESHBAY_DESIGN.md b/docs/MESHBAY_DESIGN.md
index 170081f..74c1050 100644
--- a/docs/MESHBAY_DESIGN.md
+++ b/docs/MESHBAY_DESIGN.md
@@ -959,9 +959,9 @@ buys, per the convention at the top: a client that knows which node it means to
 reach can refuse to send a code anywhere else — against a hijacked signaling path
 and against a second host of the same group. It proves *a* key, not the *right*
 one: it helps only a client that already knows which key to expect. A wrong
-signature is refused; an absent one leaves the key unproved until the ack, and a
-client holding a link code then does not send it. With the floor at 4.0 every
-reachable node signs, so that branch is one only a lowered floor could reach again.
+signature is refused, and so is an absent one: every node the floor admits signs
+whenever it has a channel binding, and one without a binding could not complete the
+proof anyway.
 
 **Channel binding is mandatory and an absent one is refused** — never degraded to
 nonce-only, which would silently drop MitM detection:
diff --git a/docs/MESHBAY_NODE_PROTOCOL.md b/docs/MESHBAY_NODE_PROTOCOL.md
index 34e2464..642e966 100644
--- a/docs/MESHBAY_NODE_PROTOCOL.md
+++ b/docs/MESHBAY_NODE_PROTOCOL.md
@@ -549,13 +549,12 @@ this is the key the client wanted. A client with no expectation learns nothing m
 than before, and the ack remains the proof of GEK possession.
 
 Client rule, from the node's answer and never from its version (§13): a `sig` that
-does not verify is a refusal (`Node challenge signature invalid`); no `sig` leaves the
-key unproved until the ack, and a client holding an invitation-link code then refuses
-to send it. A node signs whenever it has a binding, and a node with none sends no
-signature rather than an unbound one — the proof would be refused on that connection
-anyway. With the floor at 4.0 every peer a client can reach signs, so an absent `sig`
-no longer means an older node: the client's handling of it is a branch only a lowered
-floor could make reachable again.
+does not verify is a refusal (`Node challenge signature invalid`), and so is a
+challenge with no `sig` at all. A node signs whenever it has a binding, and a node
+with none sends no signature rather than an unbound one — its proof would be refused
+on that connection anyway, so refusing the unsigned challenge only says so earlier.
+With the floor at 4.0 every peer a client can reach signs, and there is no "older
+node" case to tolerate.
 
 ### 6.6 `handshake_ack` fields