Author: Brian Deery 2015-04-27 14:53:59
Published on: 2015-04-27T14:53:59+00:00
In an email to Justus, Brian Deery has expressed some critiques and worries about payment codes. He mentions that with identities explicitly tied to a payment code, bloom filter clients can have identities tied to them. There will be a 1:1 relationship between a payment code owner and their identity. An SPV client connecting to a full node who has a list of notification address can tie an identity to a bloom filter and connecting IP. Additionally, the client can use a bloom filter with a higher false positive rate; an active attacker can counter that by sending several payment codes to an individual user. Brian then suggests some data savings and privacy addition ideas, such as choosing only even or odd DER encoding to save one byte and deriving the chain value from the x value to save 32 bytes. Another suggestion is to encode the "x value" into the signature's R value to make this transaction look like a standard bitcoin transaction and get rid of the op_return completely. Finally, Brian proposes the idea of a common meeting point, where the receiver of the payment code would trial-decode all payment codes sent to a common pre-specified dead drop address (perhaps a charity address). This would trade off more work on the receiver's part to get some privacy as to the number of people interacting with that receiver.
Updated on: 2023-06-09T19:14:33.626019+00:00