comes from us for now. in the future we will offer merchants optional premium paid features to drive Bitcoin sales. we will fund the rewards with that revenue.
We compare a receiving pubkey against our database of merchant pubkeys to determine if spend qualifies for rewards. If the receiver pubkey matches then we credit the spend, if it doesn’t we do nothing.
Yes your Spark address is known to us. That is where we issue the rewards when we payout. Your Spark wallet works like an account. We don’t collect any emails or personal data.
Thank you for the criticism and concern. I definitely am always looking to improve. If you have a better design in mind please share.
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.
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.
Where does the reward money come from?
comes from us for now. in the future we will offer merchants optional premium paid features to drive Bitcoin sales. we will fund the rewards with that revenue.
Okay. Are you aware that your backend is harvesting counterparty pubkeys, over an authenticated connection that leaks a spark address identifier on every payment (before the transaction is even executed)?
Or, without getting into the code: did you know your app introduces full surveillance of sender->recipient relations?
We compare a receiving pubkey against our database of merchant pubkeys to determine if spend qualifies for rewards. If the receiver pubkey matches then we credit the
spend, if it doesn’t we do nothing.
Yes your Spark address is known to us. That is where we issue the rewards when we payout. Your Spark wallet works like an account. We don’t collect any emails or personal data.
Thank you for the criticism and concern. I definitely am always looking to improve. If you have a better design in mind please share.
Sync a list of merchants to the app, do the comparison locally.
I’ll start working on this today.
In the event of a match any concerns with how we log the reward spend?
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.
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.
https://github.com/orgs/SplitBTC/repositories
Is this using spark?
we provide a Spark wallet so that if you do not have a node you can still participate but you can connect any Lightning node or any wallet via NWC.
ahhh NWC!
I already have tons of bitcoin wallets. What makes this app different?
You earn Sats when you spend Bitcoin with merchants. We have other cool features but that’s probably the most unique one.