ECDH address

Lowercase symbols refer to numbers, uppercase symbols refer to elliptic curve points. a.B refers to point multiplication of a and B. G is the Secp256k1 generator point. H(x) means the hash (e.g. SHA256) of value X.

q = ECDH address privkey        (generated by receiver)
Q = q.G = ECDH address pubkey   (published by receiver)

p = nonce                       (generated by sender)
P = p.G = nonce point           (sent from sender to receiver)

p.Q = q.P = p.q.G               (ECDH shared secret point, known by sender and receiver but not eavesdroppers)
c = H(p.Q) = H(q.P)             (tweak, shared secret point converted to number)

sender calculates:
Q' = Q + c.G                    (bitcoin pubkey, send coins here)

receiver calculates:
Q' = Q + c.G = (q + c).G        (bitcoin pubkey, watch for incoming coins)
q' = q + c                      (bitcoin privkey, for spending incoming coins)

Another way of creating a ECDH address system is to have two receiver keypairs. One key has the power to spend the money (spend key) and the other key is for searching (scan key). Then the scan key can be sent to a third-party server to outsource the scanning. The server won't be able to steal any money because it doesn't have the spend key. Needless to say this method is not good for privacy because the server can see and track all the transactions on the ECDH address.

A tricky part of the ECDH scheme is transmitting the nonce point P from sender to receiver. There are a few different methods for this:

1. Embedding the nonce point in a OP_RETURN output. This requires the receiver to scan all blocks for check for OP_RETURN outputs and corresponding ECDH payments. It also uses extra block space, and allows estimation of how many ECDH transactions have happened.
2. Embedding the nonce point in an ECDSA signature. This requires the receiver to scan all blocks for check for ECDH payments. It also damages fungibility slightly by only allowing coins protected by ECDSA to be sent via ECDH.
3. Delegation of scanning to a third-party server (see above, Dual-key ECDH address). Ruins privacy as the server can track everything.
4. Embedding the nonce point in an extra transaction (in OP_RETURN) sent to a fixed address belonging to the receiver. This allows the receiver to outsource scanning to a server which watches the fixed address. The server can count the number of ECDH transactions but not easily track their amount, source or destination. This also uses extra block space.
5. Sending the nonce-point out-of-band (by email, for example). Requires an extra step of interactivity, and damages user-friendlyness.

ECDH addresses therefore require either a costly scan process of the entire blockchain, delegation to a third-party server which can spy on transactions, an extra step of interactivity or using the blockchain as a messaging medium.

ECDH addresses improve privacy by making it easier to avoid address reuse. An adversary can see the ECDH donation address but won't be able to easily find any transactions spending to and from it. ECDH addresses are very closely equivalent to running a http website which hands out bitcoin addresses to anybody who wants to donate except without an added step of interactivity.

However ECDH addresses do not solve all privacy problems as they are still vulnerable to mystery shopper payments; an adversary can donate some bitcoins and watch on the blockchain to see where they go afterwards, using heuristics like the common-input-ownership heuristic to obtain more information such as donation volume and final destination of funds.

Historically it has been very hard and slow to get the bitcoin ecosystem to adopt a new address type.

BIP47 is a standard for ECDH address (the BIP calls them Reusable Payment Codes). It transmits the nonce in an extra transaction with a OP_RETURN output.

The comments on the BIP47 document unanimously discourage its implementation[1]

• Privacy