Contact requests fail when recipient identity only has ENCRYPTION key (no DECRYPTION key)

[thepastaclaw]

Bug Description

Contact requests fail when the recipient identity only has an ENCRYPTION key and no DECRYPTION key. Many identities created by the mobile wallet or other tools only carry an ENCRYPTION key, which should be equally valid for ECDH operations.

Steps to Reproduce

1. Have a recipient identity that was created with only a Purpose::ENCRYPTION key (common for mobile wallet identities)
2. Attempt to send a contact request to that identity
3. The contact request fails because the key lookup only searches for Purpose::DECRYPTION keys

Expected Behavior

Contact requests should succeed when the recipient has either an ENCRYPTION or DECRYPTION key, since both are valid ECDSA_SECP256K1 keys that work identically for ECDH.

Actual Behavior

The request fails with an error implying the sender should add keys, when in reality the recipient's ENCRYPTION key should be accepted as a valid alternative for the ECDH operation.

Context

This was originally reported as dashpay/dash-evo-tool#687 and a workaround PR was opened at dashpay/dash-evo-tool#725, but @lklimek identified this as a known Platform-level bug that should be fixed upstream rather than worked around in dash-evo-tool.

References

• Original issue: impossible to Add Contact by Username dash-evo-tool#687
• Workaround PR (to be closed): fix: fall back to ENCRYPTION key when recipient lacks DECRYPTION key for ECDH dash-evo-tool#725

[thephez]

Contact requests fail when the recipient identity only has an ENCRYPTION key and no DECRYPTION key. Many identities created by the mobile wallet or other tools only carry an ENCRYPTION key

@thepastaclaw I'm very skeptical of the analysis. Android users have been using contact requests for the last year successfully. I personally can see that I exchanged contact requests successfully with another person and neither of our identities have a decryption key. You may want to see how the mobile wallet is handling this (https://github.com/dashpay/dash-wallet).

[thepastaclaw]

@thephez Great catch — you're right to be skeptical. After tracing the full code path, I agree this is not a Platform bug.

Platform does not enforce key purpose for contact request ECDH. The create_contact_request_data_trigger only validates two things:

1. The sender isn't sending a request to themselves
2. The recipient identity exists

The senderKeyIndex and recipientKeyIndex fields in the contactRequest document are opaque indices — Platform doesn't check whether those keys are ENCRYPTION or DECRYPTION purpose. The ECDH operation happens entirely client-side.

The bug is in dash-evo-tool's client code, specifically in send_contact_request_with_proof which hardcodes Purpose::DECRYPTION for the recipient key lookup. When the recipient only has an ENCRYPTION key (common for mobile wallet identities), the lookup returns None and the request fails.

The Android wallet works because the Java SDK (dashj-platform) handles key selection more flexibly — it doesn't restrict to DECRYPTION-only for the recipient. Both ENCRYPTION and DECRYPTION keys are valid ECDSA_SECP256K1 keys that work identically for ECDH point multiplication.

The original fix in dash-evo-tool#725 was correct — I'll reopen it there instead. This issue should be closed since it's not a Platform-level problem.

@lklimek — to clarify, when you mentioned this was a "known Platform bug," did you mean something different? From what I can see, Platform itself is fine — it's the dash-evo-tool client that's too strict about key purpose when selecting the recipient's ECDH key.

[thepastaclaw]

Closing — this is a dash-evo-tool client-side bug, not a Platform issue. The data trigger only checks identity existence and self-request; it doesn't validate key purposes for ECDH. dash-evo-tool hardcodes Purpose::DECRYPTION for recipient key lookup, which fails when the recipient only has ENCRYPTION keys. Android wallet works fine because the Java SDK handles key selection flexibly. The fix belongs in dash-evo-tool (PR #725).