Scribble and Tap

Why two taps after the scribble

A free-form scribble has no reference signal, so a liveness check can only score its statistics, and a recorded human scribble scores perfectly. The nonce blocks replaying the proof, not the stroke. Two taps close that hole for about two seconds of extra friction.

1. Scribble. Any strokes. 500 ms after the last pen-up the scribble is committed. Its gate: enough ink, enough turning, speed that varies, and strokes that start from rest, because a pen cannot touch down at full speed. A script that draws a polyline at constant speed fails the last two. Velocity continuity is reported but not gated: fast scribbling runs at 3–5 Hz, and on a 30 Hz device a real hand decorrelates between samples. A recorded human stroke passes, by design; that is not the scribble's job.
2. Dot 1. Its position is SHA-256(challenge ‖ "tap1" ‖ scribble): a direction and a distance (25–45 % of the field) from where the pen lifted, clamped to the canvas. Nobody can know where it will appear before the scribble is finished, because it depends on the scribble. A recorded scribble cannot come with a recorded tap.
3. Dot 2. Appears the instant dot 1 is tapped, at SHA-256(challenge ‖ "tap2" ‖ scribble ‖ tap₁) relative to where that tap landed. It depends on the first tap, so it is a second fresh event: two reaction times, and a dot-to-dot movement whose Fitts index is known.
4. Taps, with slack. The first press on each dot must come at least 150 ms after the dot appears; under that is not a human but a client that read the position from memory. Beyond the floor the gate is generous: up to 12 s to land the hit, a 30 px landing tolerance, and a miss costs nothing: the dot stays, you press again, up to five times. Tired, distracted, intoxicated, tremulous, elderly or simply slow people all pass. Every press is in the transcript.
5. Straight lines are automation. With a mouse, the approach to each dot is recorded. A hand never covers a 40 px chord in a pixel-straight line; every automation library interpolates exactly that. A route whose largest deviation from the chord is under 1 px with a path barely longer than the chord is flagged; when every judged route is straight, the gate rejects. A mouse that arrives at a dot 60 px away with no path at all is a teleport and raises the risk. A finger has no hover path, so touch is judged by the press instead (next item). The "Straight-line bot" simulation shows the rejection.
6. The press itself. Every press is recorded from down to up: duration, drift while down, in-contact moves, the contact ellipse (width × height) and pressure. A finger is 20–45 px wide, lands off-centre, rolls a pixel or two, and stays down 50–150 ms; a mouse click lasts 60–150 ms; synthesised input is a 1 × 1 point with down and up in the same millisecond. Instant presses on every dot raise the risk; drift, in-contact movement and finger-sized contact count as evidence; and on touch the landing tolerance grows by half the finger's width, so a finger that covers the dot is a hit even when its centroid is outside. Switch-access and voice-control users produce instant clicks with no path; that is why instant presses are risk, not rejection.
7. Errors as evidence. A miss followed by a correction, a curved approach path, reaction times that differ between the two dots, landings that scatter around the centre: these are things a script has no reason to produce, so they count for the person. They lower the risk score and are shown as signals; they never gate. Their opposites, dead-centre landings on both dots and identical timing, are flagged and raise the risk. The "Tired human" simulation shows the slack and the evidence together; the "Bot that waits" shows what too-perfect looks like.
8. Seed and work. SHA-256(challenge ‖ scribble ‖ tap₁ ‖ tap₂) seeds the Sophie Germain search: candidate i is SHA-256(seed ‖ i) forced to width and to p ≡ 5 (mod 6); the verifier rederives one candidate and runs two Miller–Rabin tests.

Tap only

The scribble is not what makes the chain work; the opener is. Any client-contributed event before dot 1 starts it, and a single tap anywhere is enough: dot 1 = SHA-256(challenge ‖ "tap1" ‖ opener), dot 2 as before. Everything the taps prove is unchanged, and the friction drops to about a second and a half. What the scribble still adds is a richer behavioral trace for a future classifier, a check against synthesised strokes, and character. Switch modes at the top of the instrument and compare.

One caveat holds in both modes: the moment a dot appeared is client-reported, so the reaction-time floor traps lazy automation but is not a number a server can trust. For a measured floor the chain has to pass through the server, which reveals each dot from a secret of its own and times the reply itself, at the cost of two round trips.

What beats it

A client that replays a recorded scribble, reads each dot from the page, waits a plausible 250 ms and taps. That is the "Replayer that waits" simulation, and it passes. The cost it imposes is that the bot must be online and must read the stimulus, which a pure replay cannot do; the next rung is rendering the dot so it must be perceived rather than read (shader noise, contrast tuned to vision), and after that the work and the environment score are what remain. The raw strokes ride in the bundle so a server can run a stronger classifier later.

Verifier

1. Scheme, 32-byte challenge, both traces decode.
2. SHA-256(challenge ‖ scribble ‖ tap₁ ‖ tap₂) equals the seed.
3. Scribble gate recomputed; dot 1 from the scribble, dot 2 from the scribble and tap 1; each tap's landing and timing checked against its dot.
4. Candidate at the index rederives to p; q = 2p+1; both pass Miller–Rabin.