[Paper Review] Homomorphic Payment Addresses and the Pay-to-Contract Protocol

Ilja Gerhardt, Timo Hanke|arXiv (Cornell University)|Dec 13, 2012

Cryptography and Data Security2 references11 citations

TL;DR

This paper proposes a novel payment protocol for customer-merchant transactions that eliminates the need for signed or encrypted communication by enabling customers to deterministically generate homomorphic payment addresses using a merchant's public key and a contract identifier. The protocol ensures atomic exchange of funds and receipt, with security preserved even if the merchant's infrastructure is compromised, leveraging homomorphic properties of ElGamal-type cryptosystems in Bitcoin's public blockchain.

ABSTRACT

We propose an electronic payment protocol for typical customer-merchant relations which does not require a trusted (signed) payment descriptor to be sent from the merchant to the customer. Instead, the destination "account" number for the payment is solely created on the customer side. This eliminates the need for any encrypted or authenticated communication in the protocol and is secure even if the merchant's online infrastructure is compromised. Moreover, the payment transaction itself serves as a timestamped receipt for the customer. It proves what has been paid for and who received the funds, again without relying on any merchant signatures. In particular, funds and receipt are exchanged in a single atomic action. The asymmetric nature of the customer-merchant relation is crucial. The protocol is specifically designed with bitcoin in mind as the underlying payment system. Thereby, it has the useful benefit that all transactions are public. However, the only essential requirement on the payment system is that "accounts" are arbitrary user-created keypairs of a cryptosystem whose keypairs enjoy a homomorphic property. All ElGamal-type cryptosystems have this feature. For use with bitcoin we propose the design of a deterministic bitcoin wallet whose addresses can be indexed by clear text strings.

Motivation & Objective

• To address the security vulnerability in standard bitcoin payment protocols where a compromised merchant server can redirect payments by tampering with payment addresses.
• To eliminate reliance on authenticated or encrypted communication between customer and merchant during transaction setup.
• To enable the payment transaction itself to serve as a cryptographically verifiable receipt, proving both the amount paid and the recipient.
• To allow merchants to remain pseudonymous and hide their infrastructure from customers, using a distributed filesystem for signaling.
• To design a practical extension for Bitcoin that supports labeled, deterministic wallets and secure merchant pseudonyms via public key infrastructure.

Proposed method

• Customers generate payment addresses using a homomorphic keypair construction based on the merchant’s public key and a contract identifier, ensuring deterministic derivation without revealing private keys.
• The protocol uses the homomorphic property of ElGamal-type cryptosystems to allow the customer to compute a payment address that binds the transaction to a specific contract or good.
• A one-way signaling mechanism is used where the merchant retrieves a contract from a distributed filesystem using a derived key from the payment transaction, enabling offline redemption.
• The payment transaction includes two outputs: one to the customer’s derived address and one to the merchant’s address, enabling atomic transfer of funds and receipt.
• The protocol assumes a trusted path device (e.g. hardware wallet) for signing transactions, ensuring private key security even if the customer’s main device is compromised.
• The system supports integration with Bitcoin by extending wallet functionality to support labeled, deterministic addresses and enabling verification of merchant pseudonyms via PKI or web-of-trust.

Experimental results

Research questions

• RQ1 Can a payment protocol be designed such that the customer generates the payment address without requiring any authenticated or encrypted communication from the merchant?
• RQ2 How can a payment transaction simultaneously serve as a cryptographically verifiable receipt, proving both the recipient and the purpose of payment?
• RQ3 What cryptographic properties are required to ensure that a compromised merchant cannot redirect payments or forge receipts?
• RQ4 Can a merchant remain fully anonymous and hide their infrastructure while still enabling secure, traceable transactions?
• RQ5 What modifications are needed in Bitcoin clients to support deterministic, labeled wallets and secure merchant pseudonyms?

Key findings

• The protocol successfully eliminates the need for signed or encrypted communication between customer and merchant, relying instead on deterministic address generation from the merchant’s public key and a contract identifier.
• The payment transaction itself acts as a timestamped, cryptographically binding receipt, proving both the recipient and the purpose of payment without requiring merchant signatures.
• Even if the merchant’s online infrastructure is fully compromised, funds cannot be redirected because the payment address is computed solely by the customer using homomorphic keypair properties.
• The protocol enables true merchant pseudonymity, as the merchant can operate through a distributed filesystem and hide all infrastructure from the customer.
• The protocol is compatible with Bitcoin and requires only minor extensions to existing systems, such as support for labeled, deterministic wallets and a mechanism to authenticate merchant pseudonyms via PKI or web-of-trust.
• The security of the protocol is based on the homomorphic properties of ElGamal-type cryptosystems, which are also present in ECDSA over secp256k1, making the protocol natively compatible with Bitcoin.