You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 3, 2023. It is now read-only.
A lot of sites want to reuse grinbox addresses, but this potentially leaks a lot of information to the server. It'd be better if you used stealth addresses. So:
Addresses would be A | B, with A and B being pubkeys.
The sender would calculate a one-time public key and R using the address and random data, and would use this one-time public key as the recipient's pubkey is used now.
The sender would upload R, the usual slate data, and their own pubkey to the server. If you're not already, the sender should always generate a new-per-transaction pubkey at this step - there's no reason not to.
The recipient would download all transactions from the server in the time period that they're interested in and scan each of them until they find one that they can get the private key for.
As a bandwidth optimization, you could generate a "key ID" as hash(days_since_epoch | address) (so it changes every day), and the server would require that you provide/subscribe-to the first few bits of this key ID in order to filter out a large percentage of the keys.
Since you're allowing for centralization anyway, there might be a more clever solution than just using stealth addresses, but I wasn't able to immediately think of one.
The text was updated successfully, but these errors were encountered:
Thank you very much for your proposal and for considering our service!
To be precise, users using grinbox today leak some metadata, i.e. which grinbox address transacts with which, and when. And from what IPs these requests come in from. We don’t like this, and are thinking actively about how to avoid this from happening.
As a mitigation, privacy-minded users can rotate between 2^32 different grinbox addresses, but this does not solve the problem fully as IPs are still exposed.
Your proposal is one approach, but comes at a performance and scalability cost. Once there are many transactions, users would have to download a lot of data in order to find their message.
Other potential approaches could be to introduce full TOR support, or simply encourage privacy-minded users to either run their own relay (the protocol supports federation), or connect to a relay they trust.
A lot of sites want to reuse grinbox addresses, but this potentially leaks a lot of information to the server. It'd be better if you used stealth addresses. So:
A | B
, with A and B being pubkeys.As a bandwidth optimization, you could generate a "key ID" as
hash(days_since_epoch | address)
(so it changes every day), and the server would require that you provide/subscribe-to the first few bits of this key ID in order to filter out a large percentage of the keys.Since you're allowing for centralization anyway, there might be a more clever solution than just using stealth addresses, but I wasn't able to immediately think of one.
The text was updated successfully, but these errors were encountered: