Difference between revisions of "ECDH address"
(→BIP47: Add link to comments discouraging BIP47 implementation)
|Line 49:||Line 49:|
== BIP47 ==
== BIP47 ==
[https://github.com/bitcoin/bips/blob/master/bip-0047.mediawiki 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
[https://github.com/bitcoin/bips/blob/master/bip-0047.mediawiki 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 the .
== See also ==
== See also ==
Revision as of 23:16, 22 February 2019
ECDH addresses are also called stealth addresses, reusable payment codes, reusable addresses or paynyms. Elliptic-curve Diffie–Hellman (ECDH) is a key agreement protocol that allows two parties to establish a shared secret over an insecure channel. For example, Alice and Bob can communicate cryptographic information between themselves and agree on a shared secret, Eve the eavesdropper can see _all_ their messages and yet still will not be able to calculate the shared secret.
The concept can be used in a bitcoin context by having the receiver of bitcoin publish some ECDH-information which the sender can use to calculate a shared secret. This shared secret becomes a bitcoin address which the sender sends money to. The receiver can calculate the corresponding private key to have access to the money.
How it works (single key)
Lowercase symbols refer to numbers, uppercase symbols refer to elliptic curve points.
a.B refers to point multiplication of
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(d.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)
Dual-key ECDH address
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 track all the transactions on the ECDH address.
Transmitting the nonce point
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:
- 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.
- 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.
- Delegation of scanning to a third-party server (see above, Dual-key ECDH address). Ruins privacy as the server can track everything.
- 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.
- Sending the nonce-point out-of-band (by email, for example). Requires an extra step of interactivity, and damages user-friendlyness.
ECDH addresses there 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.
The comments on the BIP47 document unanimously discourage its implementation