pull down to refresh
ok thank you for your critiques I think this is much much better now. Old endpoints still exist for compatibility with older versions but we will remove them after the updates are approved in app/play stores.
We changed the flow so merchant matching happens on device. The backend now exposes a cached list of hashed eligible merchant pubkeys. The client normalizes and hashes the recipient pubkey the same way, compares locally, and only treats the payment as reward eligible if there is a match. If there is no match, no reward spend claim is sent.
For a payment that the client already determined is reward eligible, after payment completion the client sends an encrypted claim to our server. That claim currently includes the payment hash, merchant pubkey hash, preimage, BOLT11 invoice, sats amount, USD cent amount, and timestamp.
On the backend we decrypt the claim and verify consistency before crediting it: the preimage must hash to the payment hash, the BOLT11 invoice must decode and verify, the invoice payment hash must match the claim, the invoice destination pubkey must hash to the claimed merchant hash, the merchant hash must still be in our eligible merchant set, and the invoice amount must match when the invoice includes an amount.
We do not store the raw preimage or raw invoice. For the reward spend ledger we store hashes of the payment hash and invoice, the merchant pubkey hash, the amounts, user and month metadata, and a verification method. The payment hash has a uniqueness constraint after hashing so the same payment cannot be credited twice.
This is still not perfect privacy, and we are very open to improving it. I looked into ZK approaches but did not find a practical way yet to prove reward eligibility and prevent duplicate claims without passing enough data for the server to verify the payment claim. If there is a way to pass less data, store less data, or do this with a stronger privacy model, critiques and suggestions are very welcome.
Ideally: to not reverse dox your merchants, hash the list entries.
The log message back, its a bit broad. Ideally its a zero knowledge proof and a clear amount, but that's hard and not mature yet. For now, I'd just make sure that its encrypted and strip any data that you don't need. (After all, everything you don't know is something you're not liable for and cannot get subpoenaed for.)
That's something that ultimately you just want to disclose in docs / faqs. Just be precise about what you keep and why. This is the business in the end.