Problem:
The current did:btc design allows the controller of a DID UTXO to rotate the subject public key (or perform any other update) in a single transaction. If the controller private keys are compromised, an attacker can immediately replace the verification methods and take permanent control of the DID.
Because revocation and updates both require spending the same DID UTXO, there is a pure race condition: the first confirmed transaction wins. If the attacker broadcasts a key-rotation or finalization transaction first, the legitimate owner’s pre-signed revocation transaction becomes useless. The spec correctly notes this risk, but provides no protocol-level protection against it.
Proposed Solution:
Introduce an optional timelock that applies only to key rotation and DID updates, while leaving revocation completely unrestricted.
When a DID is created, the controller can choose to embed a relative timelock (e.g. CSV or CLTV in the Taproot script path) that must elapse before any update transaction that modifies verification methods (vm), service endpoints, or other content can be confirmed.
Revocation (spending the UTXO to the OP_RETURN byte d) would remain instant and unaffected by the timelock.
The timelock could be configurable at DID creation time (e.g. 100 blocks ≈ 16–17 hours, 144 blocks ≈ 1 day, etc.) or a sensible default could be recommended in the spec.
This mirrors the timelock pattern already proven in the Lightning Network: updates (channel state changes) are delayed, but punitive/revocation transactions can be broadcast immediately to protect the honest party.
Security Benefit:
In a compromise scenario the attacker’s best outcome would be to destroy the DID (by broadcasting a revocation transaction themselves). They would no longer be able to silently steal control by rotating keys without giving the legitimate owner a known grace period to revoke first. The owner could simply keep a pre-signed revocation transaction offline and broadcast it the moment they detect compromise.
Problem:
The current did:btc design allows the controller of a DID UTXO to rotate the subject public key (or perform any other update) in a single transaction. If the controller private keys are compromised, an attacker can immediately replace the verification methods and take permanent control of the DID.
Because revocation and updates both require spending the same DID UTXO, there is a pure race condition: the first confirmed transaction wins. If the attacker broadcasts a key-rotation or finalization transaction first, the legitimate owner’s pre-signed revocation transaction becomes useless. The spec correctly notes this risk, but provides no protocol-level protection against it.
Proposed Solution:
Introduce an optional timelock that applies only to key rotation and DID updates, while leaving revocation completely unrestricted.
When a DID is created, the controller can choose to embed a relative timelock (e.g. CSV or CLTV in the Taproot script path) that must elapse before any update transaction that modifies verification methods (vm), service endpoints, or other content can be confirmed.
Revocation (spending the UTXO to the OP_RETURN byte d) would remain instant and unaffected by the timelock.
The timelock could be configurable at DID creation time (e.g. 100 blocks ≈ 16–17 hours, 144 blocks ≈ 1 day, etc.) or a sensible default could be recommended in the spec.
This mirrors the timelock pattern already proven in the Lightning Network: updates (channel state changes) are delayed, but punitive/revocation transactions can be broadcast immediately to protect the honest party.
Security Benefit:
In a compromise scenario the attacker’s best outcome would be to destroy the DID (by broadcasting a revocation transaction themselves). They would no longer be able to silently steal control by rotating keys without giving the legitimate owner a known grace period to revoke first. The owner could simply keep a pre-signed revocation transaction offline and broadcast it the moment they detect compromise.