Gregory Maxwell

Maxwell’s work connects Bitcoin development with privacy and security. He cofounded Blockstream and served as CTO, its chief technology officer. On 19 January 2018, the company announced that he had left that role to focus on Bitcoin development. This is the announcement date, not proof of the exact departure day. Nor does the announcement establish his present employment. The concrete problems he worked on matter more here than a job title. [1]

Imagine several people combining their payments into one transaction. Each contributes inputs, meaning previously received coins now being spent, and signs to authorize their use. An observer therefore cannot reliably infer common ownership from their inclusion in the same transaction alone. Writing as gmaxwell on 22 August 2013, Maxwell explained this approach as CoinJoin. He explicitly acknowledged earlier limited use; the technique did not require changes to Bitcoin’s protocol rules. [2]

How do the participants agree on what to sign? A coordinator can assemble a simple CoinJoin, but each participant first checks their output: where their funds are going and how much. Only then do they sign their inputs. This does not give the coordinator discretion to spend their coins. Yet in a simple implementation, the coordinator may know the input-to-output links. A participant refusing to sign can also stop the round. Thus theft protection, availability and privacy are distinct properties. [2]

Ordinary Bitcoin transactions expose amounts. Confidential Transactions address a different problem from merely combining payments: they hide amounts in cryptographic commitments. These bind a value without revealing it, while their properties also allow sums to be checked. Maxwell’s explanation in Elements builds on Adam Back’s proposal from 2013. Its use in Elements is not deployment of this feature on Bitcoin’s base network. Hiding amounts alone also leaves the transaction graph, the web of connections between payments, visible. [3]

As arithmetic, 10 = 11 + (-1). As a transfer model ignoring fees, it exposes a problem: the total balances, but a positive output exceeds the starting value, offset by a meaningless negative output. In Confidential Transactions, modular overflow can cause a similar effect when calculation wraps around the number system’s boundary. A range proof is therefore needed. It verifies that the hidden amount lies within an allowed interval without revealing the exact value. Privacy must not create a way to manufacture extra money. [3]

Why publish backup spending conditions when everyone agreed and those conditions were never needed? Maxwell’s Taproot proposal of 23 January 2018 showed how a joint signature could conceal the existence of alternative spending conditions. When the parties cooperate, a more elaborate agreement can appear like an ordinary payment authorized by a key. The post’s date is not the network activation date. Further work separates the idea from adoption: discussion, precise rules and acceptance by network participants. [4]

The final specification BIP 341, a public technical document defining Taproot’s rules, names Pieter Wuille, Jonas Nick and Anthony Towns as authors. Its key path can use a signature without revealing the presence of an alternative script. A script is a program expressing spending conditions; if the script path is used, the selected program and proof of its inclusion are revealed. This does not diminish Maxwell’s original idea, but it does rule out crediting him with sole authorship of the final rules. [5]

Sending money also requires a correctly written address. Pieter Wuille and Greg Maxwell authored BIP 173, which describes Bech32 for native SegWit addresses. Its checksum consists of characters that help detect an error in the encoding. It does not verify recipient identity or who holds the private key. A valid but substituted address can pass the check. Bech32 therefore addresses a different problem from CoinJoin or hidden amounts; their benefits should not be confused. [6]