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
I haven't checked features or functionality for this, but assuming based on the release notes of 2.3.4, it may be a good idea to support deterministic payer ID/key for each contact.
This way, contacts can attribute payments from the same person but payments cannot be correlated between senders. This is how, for example, MAC addresses for Apple's Private Network Addresses work, where the phone will use a persistent MAC for a given network.
I advise this is the default as it's a good balance between privacy and usability, but the other two options should still be available.
Thanks for an awesome project!
The text was updated successfully, but these errors were encountered:
That's a good idea. There are several options, like using a mix of the user's payer key + a static element of the payee's offer to build this deterministic payer key. Or an attribute from the device.
We're still iterating so I think we can try a few things and maybe make a BLIP eventually.
I haven't checked features or functionality for this, but assuming based on the release notes of 2.3.4, it may be a good idea to support deterministic payer ID/key for each contact.
This way, contacts can attribute payments from the same person but payments cannot be correlated between senders. This is how, for example, MAC addresses for Apple's Private Network Addresses work, where the phone will use a persistent MAC for a given network.
I advise this is the default as it's a good balance between privacy and usability, but the other two options should still be available.
Thanks for an awesome project!
The text was updated successfully, but these errors were encountered: