Mike Hearn is a Bitcoin developer and coauthor of several BIPs, documents describing proposed technical solutions. He contributed to the bitcoinj library and to methods for checking connections, selecting relevant transactions and communicating during payment. Following a payment from a phone wallet to a merchant makes his contribution easier to understand.
Someone building a Bitcoin wallet does not have to write every part of its communication from scratch. They can use a library: a collection of ready-made functions on which to build an application. bitcoinj is one such library. Its AUTHORS file lists Mike Hearn among many contributors and points to the history of changes in Git. This lets readers trace specific contributions. It does not mean Hearn wrote every feature himself or leads the whole project today. [1]
bitcoinj is a Java library that can manage a wallet and send or receive transactions without a local installation of Bitcoin Core. A phone can benefit from SPV, short for Simplified Payment Verification: it works with block headers and transactions relevant to the wallet instead of fully checking every transaction. This saves data and device resources. The documentation also describes experimental full verification. These are different modes; lighter operation is not simply the same validation of every rule performed faster. [2]
Imagine a laptop waking from sleep. Its connection to another node may appear open even though it no longer works. Hearn’s BIP 31 lets it send a ping carrying a nonce, here a number identifying a particular query. The peer returns that number in a pong message. With protocol versions above 60000, this pairs requests with replies and measures response time. It checks communication: a reply by itself does not prove node honesty or the validity of a payment. [3]
Why should a phone download transactions that have nothing to do with it? BIP 37, written by Hearn and Matt Corallo, describes a Bloom filter: a compact tool for selecting possible matches. filterload sets the filter, filteradd adds an item and filterclear removes the filter. An unrelated transaction can slip through; this is a false positive. A more precise filter reduces traffic, but can make it easier for a peer to link transactions to the wallet’s IP address. Saving bandwidth does not automatically protect privacy. [4]
The phone needs to know whether a received transaction belongs to a particular block. The merkleblock message in BIP 37 supplies data for a Merkle proof: a few data fingerprints, or hashes, let it check the transaction’s link to the combined fingerprint in the block header. It need not download the whole block. However, the proof does not rule out omitted transactions. SPV also does not replace a full check of whether the transactions are valid. The bitcoinj documentation explains the danger of an attacker controlling all the wallet’s connections and choosing what it gets to see. [4] [5]
When buying something, you need to know both the amount and the recipient. BIP 70, written by Gavin Andresen and Hearn, introduces PaymentRequest for this purpose. It carries payment details: outputs specifying where the transaction should assign funds, the amount and an optional expiry time. X.509 certificates can authenticate the merchant’s identity, much as they do for web servers. But the protocol also permits pki_type none, a request without this authentication. The request format alone therefore does not establish a certified merchant identity. [6]
If the request specifies a payment server, the wallet sends it a Payment message after you authorize payment. The PaymentACK response may say that the shop has accepted the payment for processing. This is useful to the customer, but it is still a statement from the merchant’s server, not proof of block confirmation. Similarly, refund_to only specifies where the merchant may send a refund; it does not return funds by itself. An application must distinguish messages about a payment from the actual movement of money. [6]
An older guide can leave you expecting its procedure to work everywhere. The registry marks BIP 70 as Deployed, indicating that it has been implemented. Yet the release notes for Bitcoin Core 0.20.0 record the complete removal of its support from that program. There is no contradiction: a historically used specification need not be supported by every current client. Hearn’s work helps explain how wallets developed; putting a procedure into practice also requires checking the particular software and version. [6] [7]
For the clearest picture, read this entry together with Jeff Garzik, Gloria Zhao, Merkle Tree. The reverse links also lead from Jeff Garzik, Gloria Zhao.