AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Informational 20 Bitcoin

feat(core/thp): support receive-side THP ACK piggybacking

Public commit record

What the developer wrote

Authored by Roman Zeyde

100/100 · Strong
feat(core/thp): support receive-side THP ACK piggybacking

The host will detect device support via the bumped minor version
(from `2.0` to `2.1`) - will be done in a subsequent commit, since
it affects the pairing code entropy - resulting in UI fixture diffs.

The device will detect host support via the
ACK bit of `HANDSHAKE_INIT_REQ` message (previously set to 0).

Due to event loop restarts, the last message sent to the host should
be ACKed using a non-piggybacked THP ACK message.
Otherwise, the piggybacking message will be dropped and the host will
need to re-transmit it.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Names security-relevant behavior explicitly
The short version

What changed, and why it matters

This commit adds a new optional efficiency feature to Trezor's THP (Trezor Host Protocol) that lets acknowledgements (ACKs) be attached to normal messages instead of sent separately. It is a feature implementation, not a fix for a known vulnerability. The change includes a compatibility handshake so older hosts fall back to non-piggybacked ACKs. There is no direct evidence in the commit that this introduces a security bug, but any protocol change carries some risk of subtle state-machine issues.

Recommended action

Treat as a normal feature commit. Reviewers should verify that the new ACK-piggybacking state machine correctly handles retransmissions, sequence-bit toggling, and the event-loop-restart edge case described in the commit message. No immediate security response is indicated by the supplied materials.

Security signals we found

01

Protocol state-machine change in alternating-bit reliability layer

02

New handshake negotiation bit derived from host control byte

03

Addition of `EMPTY_ACK_PAYLOAD` return path and reassembler state preservation

04

Conditional ACK handling branch added to `recv_payload()` loop

05

No security-relevant keywords (fix, CVE, vulnerability, etc.) in commit message or changelog

Risk score

Why this scored 20/100

Our methodology →
Potential impact 2/30
Exploitability 2/25
Stealth signal 3/15
Affected reach 3/15
Confidence 7/10
Evidence quality 3/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.