From the spec: The scheme requires the server to detect nonce reuse with reasonable reliability. However, there might be no need for a zero false pos

From the spec: The scheme requires the server to detect nonce reuse with reasonable reliability. However, there might be no need for a zero false positive rate, because if an attacker needs to make 10,000 requests to have one succeed, that's possibly an acceptable trade-off. Therefore, the server could use data structures such as Bloom filters or cuckoo filters to store tokens that it has witnessed. The parameters of these structures can be chosen to ensure a false-positive probability of any given amount. Cuckoo filters may be more efficient but Bloom filters may be easier to construct. I don't think this makes sense. "False positive" for a Bloom filter means it thinks an item was previously inserted when it wasn't really. If the filter represents a set of used nonces, the result of seeing an item as previously inserted would have to be blocking the request as a duplicate: therefore a false positive would cause a fraction of legitimate requests to be blocked, not malicious requests to be allowed as the first paragraph seems to imply. This result wouldn't necessarily be unacceptable either, especially if there was some mechanism for the browser to automatically retry a HTTP request with a new token if it received a "reused token" error. However, this behavior would have to be specified, and it's somewhat tricky: it's also possible for tokens to be (actually) reused by accident, e.g. if the user restores their system from a backup or a VM snapshot. In that case, it would make more sense for the browser to respond to a duplicate token error by throwing away all its tokens, since it would have no way to know which of them were clean. Then again, if the Bloom filter is big enough that the probability of a false positive is very low, even spuriously forcing the user to complete another CAPTCHA may not be the end of the world.