[Bounty] Implement sending to Silent Payment addresses - 0.01 BTC

[sethforprivacy]

Describe the new feature or improvement you would like to see in Passport's firmware.

A bounty has been opened on silentpayments.xyz from a trusted, anonymous source to implement sending support in Passport firmware to Silent Payment addresses.

I wanted to open an issue here to raise awareness and ensure that prospective contributors are aware of open bounties for Passport from outside sources.

You can learn more about the bounty at https://silentpayments.xyz/docs/bounties/ and find more development resources focused on Silent Payments at https://silentpayments.xyz/docs/developers/.

Explain the specific use case or scenario where this feature would be valuable to users.

Silent Payments are growing in adoption rapidly, and one of the best ways we can aid that growth is implementing sending support in Passport.

Ideas for implementation

https://silentpayments.xyz/docs/developers/

Screenshots/Design

No response

Additional Context

No response

[Larrychuks]

It's real

[qwldcl-del]

👋 Hi! I'd like to work on this bounty. Please assign to me!

[qwldcl-del]

Hi! I'm interested in working on this bounty. I'll implement the Silent Payment sending support for Passport firmware. Let me start working on this feature.

[220nightmore-spec]

I am interested in working on this bounty and have started reviewing the current dev-v2.4.0 firmware and BIP352 v1.1.1 test vectors.

Passport is an air-gapped PSBT signer, so the host cannot derive a Silent Payment output from an xpub-only wallet without a device-assisted protocol. Before I lock in the integration design, could a Foundation maintainer confirm the expected boundary?

1. Should the firmware accept a proprietary PSBT output field containing the 66-byte Silent Payment recipient data and replace a placeholder output before signing, or is a two-round flow expected where Passport returns the derived output plus a DLEQ proof and the host returns the final PSBT for signing?
2. Is an Envoy/companion change in scope for the bounty, or should this PR define only the firmware-side protocol and simulator fixtures?
3. Would adding a small BIP352 sender module using the existing trezorcrypto.secp256k1.multiply primitive, official send vectors, and full PSBT/simulator integration tests be the preferred implementation direction?

I will keep all work on deterministic public test vectors only; no real seed, private key, or funded transaction is needed. I can proceed with the core sender and vector tests while the host-device protocol is clarified.