On Fri, Apr 24, 2015 at 10:58 PM, Gregory Maxwell <gmaxwell@gmail.com> wrote:

So this requires making dust payments to a constantly reused address
in order to (ab)use the blockchain as a messaging layer.

Indeed, this is more SPV compatible; but it seems likely to me that
_in practice_ it would almost completely undermine the privacy the
idea hoped to provide; because you'd have an observable linkage to a
highly reused address.

I agree that the output associated with notification transactions would require special handling to avoid privacy leaks. At a minimum they'd require mixing or being donated to miners as a transaction fee.

It would also more than double the data sent for the application where
'stealth addresses' are most important: one-time anonymous donations
(in other contexts; you have two way communication between the
participants, and so you can just given them a one off address without
singling in the public network.)

Communication is only one way, except for the case in which the recipient wants to send a refund. Assuming no refund and only a single anonymous donation in the lifetime of the sender's identity, payment codes would require 65 bytes vs 40 bytes for stealth addresses.

As soon as the sender sends more than one donation to the same recipient, payment codes show an space advantage over stealth addresses.

This kind of binding was intentionally designed out of the stealth

address proposal; I think this scheme can be made to work without any
increase in size by reusing the payment code as the ephemeral public
key (or actually being substantially smaller e.g. use the shared
secret as the chain code, but I should give it more thought)

With 97 byte standard OP_RETURN values the ephemeral public

key could be appended to the chain code, but that's undesirable for other reasons.

This is fundamentally more expensive to compute; please don't specify
"uncompressed".

Taking the SHA512 of something less than 512 bits seemed wrong.

This appears incompatible with multisignature; which is unfortunate.

I agree. I could not find a straightforward way to express a multisignature payment code in less than 80 bytes.

I'm disappointed that there isn't any thought given to solving the
scanning privacy without forcing non-private pure-overhead messaging
transactions on heavily reused addresses. Are you aware of the IBE
approach that allows someone to request a third party scan for them
with block by block control over their delegation of scanning?

I suspect this is a case where we just can't have all the features we want.

In this proposal I optimized for non-reliance on third party services and a guaranteed ability to recover spendable funds from a seed backup.

Gaining those two features resulted in some tradeoffs as you noted, but I think there are enough benefits to make them worthwhile.

In particular, payment codes could be the basis for a Heartbleed-free payment protocol that can positively identify customers and automatically provide refund capabilities in a merchant-customer relationship. A merchant only requires one payment code which they can safely use for all their customers, meaning they only ever need to associate 65 bytes with their identity to allow customers to make sure they are paying the right entity.

Exchanges could restrict bitcoin withdrawals to a single payment code known to be associated with their identified customer. This would make thefts easier (without involving address reuse as in locking withdrawals to a single P2PKH address).

In some jurisdictions the ability to prove that withdrawals are sent to a positively-identified party, rather than arbitrary third parties, might move some Bitcoin businesses out of money transmitter territory into less onerous regulatory situations.