Implement stealth payment scanning service#33
Conversation
Co-authored-by: jkoizum <jkoizum@wgu.edu>
|
Cursor Agent can help with this pull request. Just |
AVM-26 `[14/15] Implement Payment Scanning Service`
2. Integration with GhostSolPrivacyUpdate: 3. Create
|
|
@codex review please run a code review on the latest PR head. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 55d21cbb5f
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| // Use X25519 (Curve25519 ECDH) | ||
| // nacl.box.before computes the shared secret | ||
| const sharedSecret = nacl.box.before(publicKey, secretKeySeed); |
There was a problem hiding this comment.
Use matching X25519 keypairs for shared-secret derivation
When a sender uses generateStealthAddress() and the recipient later scans, nacl.box.before is being fed Solana Keypair.generate() Ed25519 public keys/seeds rather than a Curve25519 keypair. The sender computes with the ephemeral seed plus viewing public key, while the scanner computes with the viewing seed plus ephemeral public key, so the shared secrets generally differ; in the normal payment flow deriveStealthAddressFromEphemeral() derives a different address than the one paid and PaymentScanner never reports the payment.
Useful? React with 👍 / 👎.
| // TODO: Replace with proper Ed25519 point addition | ||
| const result = new Uint8Array(32); | ||
| for (let i = 0; i < 32; i++) { | ||
| result[i] = pubkey1[i] ^ pubkey2[i]; |
There was a problem hiding this comment.
Derive a spendable stealth address keypair
When SOL is sent to the address returned by generateStealthAddress(), the recipient must later sign with deriveStealthSpendingKey(), but this address is constructed by bytewise XORing two Ed25519 public keys while the spending key XORs secret bytes. That secret key's Ed25519 public key will not equal this XORed destination address, so signatures for funds sent to these stealth addresses will be rejected and the funds are effectively unrecoverable.
Useful? React with 👍 / 👎.
This pull request contains changes generated by a Cursor Cloud Agent