Wei Dai is a cryptographer and the original author of the Crypto++ library. His 1998 b-money proposal described how people using digital pseudonyms might keep monetary accounts and enter contracts. Bitcoin cites his work, while using its own network design and rules.
When programmers need to encrypt a message or verify a digital signature, they need not write every procedure from scratch. They can use a cryptographic library: a collection of functions for handling protected data. Wei Dai originally wrote one such library, Crypto++, in C++. It is actual software that can be incorporated into an application. His b-money is a different kind of contribution: a written proposal for a monetary system. The existence of a working library cannot be used as proof that a network implementing that proposal also operated. Understanding his contribution means following these two strands separately. [3]
In November 1998, Wei Dai raised a question familiar even from everyday online shopping: how can people cooperate without disclosing their identities? In b-money he proposed two protocols, or sets of rules, for shared accounting and contracts. Public keys would serve as pseudonyms, and messages would carry digital signatures. An untraceable network, however, was a starting assumption, not something the proposal itself delivered. The proposal does not guarantee anonymity. Dai described the first version as impractical because of its demanding message-broadcast requirements. We are reading a considered design, not instructions for an already functioning anonymous service. [1]
Imagine Anna has a b-money balance of 5 units and sends Tom 2. In the first version, each participant keeps a copy of the accounts. Her signed message tells the others to debit her account and credit his, leaving Anna with 3 units. A message that would produce a negative balance is ignored. A digital signature verifies authority for the instruction, but shared accounting also needs rules for delivering messages. Bitcoin later used the UTXO model: it tracks specific transaction outputs that remain available to spend. A similar aim therefore need not mean the same accounting method. [1]
The second b-money version assigns accounting to a subset of participants called servers. That reduces others’ workload, but raises the question of how to supervise the bookkeepers. Servers must post deposits that can cover penalties, and periodically publish and commit to their databases: publicly stand behind a particular set of records. Users check their own balances and whether account totals exceed money issued. Payment recipients also check processing with randomly chosen servers. A deposit therefore does not magically remove trust. It forms part of the proposed oversight of the people and machines managing the accounts. [1]
Original b-money creates units for solving a computational problem. Their quantity would reflect the computation’s cost, measured in a standard basket of commodities. This basket provides a common cost measure; it does not set the price someone would pay for a unit in the market. Yet computers improve, and their actual costs are not known to everyone. Dai identified this weakness and proposed an auction alternative in an appendix: account keepers negotiate the quantity of new money, while would-be issuers compete through computational bids. This is neither Bitcoin’s BTC issuance schedule nor a market price rule. Part of the proposal’s value is acknowledging a hard problem and exploring another approach. [1]
The proposal reaches beyond payments. Consider a translation job: a signature can establish agreement to a contract, but not the quality of the delivered text. Contracts in b-money therefore involve deposits, agreed compensation for breach and help from an arbitrator. If the parties still cannot agree, they submit arguments and individual account keepers make their own determinations. This illustrates the difficulty of putting human disputes into a digital system. Bitcoin Script, the language of conditions for spending an output, instead evaluates precisely specified technical conditions. It cannot itself judge whether a promised translation was any good. [1]
Satoshi Nakamoto listed the 1998 b-money proposal as reference 1 in the Bitcoin whitepaper, the document explaining Bitcoin’s design. Readers can follow a specific intellectual connection: digital money without a shared administrator was being explored before Bitcoin. A citation does not mean Bitcoin adopted every proposed mechanism. The accounts, issuance and dispute procedures in b-money differ from Bitcoin’s. These are related ideas, not identical mechanisms. Nor does the reference reveal who was behind the name Satoshi Nakamoto. Comparing documented texts tells us more about this history than treating a citation as evidence of the author’s identity. [2]
The Crypto++ story continues through fixes, tests and other developers’ work. The project history records that Wei Dai handed daily operations to the community in June 2015. For library users, that underlines an important point: both the original author and the specific version and correct use of its functions matter. A library can provide signing or encryption tools, but does not by itself solve secure key storage or an entire wallet design. Application developers must read documentation, follow fixes and verify their own use. Recognizing the author’s contribution goes hand in hand with examining today’s software. [3]
For the clearest picture, read this entry together with Adam Back, Nick Szabo, b-money, Satoshi Nakamoto. The reverse links also lead from b-money, Bit Gold, Adam Back, Nick Szabo.