feat: support private shielded payments to Platform identities without DashPay contacts

[ktechmidas]

Support private payments from the shielded pool to a DPNS-resolved Platform identity, without a DashPay contact, without requiring the recipient to be online, and without publishing a reusable shielded address.

Current protocol gap

• IdentityCreditTransfer accepts an identity ID but exposes sender, recipient, and amount.
• ShieldedTransfer hides all three but requires Orchard receiving information; an identity ID is not an Orchard receiving/spending key.
• Unshield can pay a Platform address but exposes the destination and amount.
• A shielded top-up of an existing identity would still reveal the recipient and balance increase because identity balances are public.
• Publishing a permanent Orchard receiver in a profile/document creates a durable identity-to-receiver mapping and harvest-now/decrypt-later exposure.

Feasible construction

One option is an identity-claimable shielded commitment:

1. Alice resolves Bob's identity, chooses randomness r, and spends shielded notes into a pending commitment conceptually binding Commit(identityId, r, value, claimKey).
2. Claim data is encrypted to an identity-authenticated claim/inbox key so Bob can discover it later.
3. Bob claims it by producing a zero-knowledge proof that creates a normal Orchard output note.

Possible public proof inputs:

• An accepted Platform identity-state root
• The pending-payment commitment
• A claim nullifier
• The resulting Orchard note commitment

Private witness:

• Identity ID and commitment opening
• A private key corresponding to an active key under that identity
• Identity-tree membership path
• Hidden value and Orchard output data

The proof must enforce identity-key control, commitment opening, unclaimed status, value conservation, and exclusive ownership of the resulting note without revealing the identity or amount. The nullifier prevents replay/double claims. Because Alice does not control Bob's identity/claim key, this avoids the unsafe shortcut where Alice generates and retains a one-time spending key.

Verifying existing ECDSA/BLS identity authorization inside Halo 2 may be expensive; a dedicated Pallas-native shielded claim/inbox key associated with the identity may be simpler.

An alternative is an identity-authenticated stealth/inbox key from which Alice can derive a unique Orchard destination public key—but not its spending key—allowing direct note creation without a separate claim transition.

Required properties / decisions

• Sender, recipient, and amount remain absent from public state.
• Recipient can be offline and later discover the payment privately.
• Sender cannot reclaim or race the recipient unless an explicit expiry/refund rule permits it.
• Define identity-key rotation/revocation, recovery, scanning, fees, spam resistance, and optional expiry.
• Avoid identity-specific queries that disclose which recipient is scanning.
• Define the archival/quantum threat model; rotating public documents does not erase previously published receivers.

Related

#3813 establishes the shielded-to-identity boundary for creating a new identity. This request concerns privately paying an existing identity.