Below are 3 emails 2008–2009 between cryptographers Wei Dai & Satoshi Nakamoto; they were quoted in the Sunday Times’s 2014-03-02 article “Desperately seeking Satoshi; From nowhere, bitcoin is now worth billions. Where did it come from? Andrew Smith set off to find Satoshi Nakamoto, the mysterious genius behind the hit e-currency”.
The then-unknown Satoshi Nakamoto contacted Wei Dai, one of the few cryptographers to even dabble in e-currency speculation at the time, for citation details for his draft Bitcoin white paper, and to advertise his ideas. Wei Dai was not particularly interested but told Nakamoto about Nick Szabo’s uncited Bit Gold; in retrospect, Wei Dai interprets this as evidence that Satoshi is not Nick Szabo.
The title does not mention Bitcoin, and the abstract is not identical to the final one, which is slightly better written (eg. no “broadcasted” typo); a word-level diff of the abstracts using Mergeley.com.
The bit about Adam Back has been mentioned before; on 2013-04-18, Adam Back posted to the BitcoinTalk forums a self-introduction mentioning that
Quote from: Adam Back on April 18, 2013, 11:27:49 AM UTC…So anyway I know a few things about ecash, privacy tech, crypto, distributed systems (my comp sci PhD is in distributed systems) and I guess I was one of the moderately early people to read about and try to comprehend the p2p crypto cleverness that is bitcoin. In fact I believe it was me who got Wei Dai’s b-money reference added to Satoshi’s bitcoin paper when he emailed me about hashcash back in 2008. If like Hal Finney I’d actually tried to run the miner back then, I may too be sitting on some genesis/bootstrap era coins. Alas I own not a single bitcoin which is kind of ironic as the actual bitcoin mining is basically my hashcash invention…
The “pre-release draft” link is now broken. I have tried to refind it:
- the original fly-by-night filehosting site disappeared years ago, and does not appear to have been renamed or moved
- the filehosting download page & PDF are unavailable in the Internet Archive
- the earliest version of the whitepaper on Bitcoin.org in the Internet Archive is a later draft, using the name “Bitcoin” (unsurprisingly); looking at the full list of mirrored files for that domain, there don’t appear to be any other PDFs in the snapshots which might be an earlier still draft & possibly the original
- Google searches for queries like “ecash-pdf” and variants (sometimes adding in “Satoshi Nakamoto” since he was using that nick at the time even if he had not settled on “Bitcoin” as a name) have turned up no mirrors or people discussing that version of the whitepaper who might have copies
- a more targeted search on BitcoinTalk did not turn up any copies
- the whitepaper was never checked into the original Subversion repository set up after the alpha code was released, so no revision history there either
- I asked them and learned that early correspondents Wei Dai, Adam Back, and Gregory Maxwell do not have copies. (I also asked Hal Finney but did not expect a reply given his condition & did not receive one before he passed away 2014-08-28.)
If anyone has a copy of it or a tip as to where it might be or who might have it stashed away, please contact me. It would likely shed some further insight on the development of Bitcoin and how Satoshi had his key insight of proof-of-work.
A request on the original “cryptography” mailing list yielded a SHA-256 hash of a draft paper earlier than the current bitcoin.org-hosted version, which then turned up a matching bitcoin.pdf (rehosted locally). This one has a few noticeable differences: the Vistomail email address, the final title, a few word changes (“digital signatures provide part” rather than “offer”) etc.1.
Is this the earliest draft of the paper, the one Satoshi sent to Wei Dai? No:
-
Satoshi’s initial email to Dai is dated “August 22, 2008”; the metadata for this PDF (
pdftk bitcoin.pdf dump_data) yields as theCreationDatethe value20081003134958-07'00'—without getting into the gory details of PDF metadata formatting, this implies 2008-10-03 or a bit over a month later, which is consistent with the local date mentioned in the cryptography ML email. (This is however an earlier draft than the final draft onbitcoin.org, which is dated20090324113315-06'00'or 2009-03-24; interestingly, the timezone differs: −7 vs −6.) -
Satoshi says in the Dai email that the URL is
...ecash-pdf.html, which is an auto-link generated by the filehost, suggesting the filename wasecash.pdfand notbitcoin.pdf‘Ecash’ or ‘e-cash’ appears elsewhere in early Satoshi materials. In particular, an anonymous reader points out to me that:
…while
bitcoin.orgwas registered on 2008-08-18,e-cash.orglooks to have been registered on 2008-07-20. Seems likely that Satoshi also registered this one and then switched his mind later on and went with ‘bitcoin’ instead.Or Weinberger notes that:
Did you know? A day before the
http://bitcoin.orgdomain was first registered, someone purchasedhttp://netcoin.orgusing the same registrar. Looks like Satoshi was contemplating between the two names and later droppedhttp://netcoin.orgAccording to Wayback Machine no content was ever present on the
http://netcoin.orgdomain except for only after it was repurchased by another person later on.I’ve discovered this by looking at all domains purchased around the same time by AnonymousSpeech. It’s truly amazing that you can still reveal new information on such a researched subject. Paid subscription for domaintools’s research features which includes every historical record for this domain.
- Satoshi says also that the title is “Electronic Cash Without a Trusted Third Party”, but in this October 2008 version, the title has already changed to “Bitcoin: A Peer-to-Peer Electronic Cash System”
-
Satoshi’s pretext is getting the right citation for Dai’s B-money, and he implies there is either no citation to Dai currently (consistent with Adam Back’s claim to have noticed the absence and told Satoshi) or it would be to ‘2006?’ (his quoted example citation); however, this file has the full correct citation
[1] W. Dai, 'b-money,' http://www.weidai.com/bmoney.txt, 1998.—dated to 1998 (as Dai tells Satoshi), not 2006 (as was Satoshi’s best guess).
Footnotes
-
A fuller diff:
↩[-satoshi@vistomail.com-] {+satoshin@gmx.com+} ...Abstract. A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without [-the burdens of-] going through a financial institution. Digital signatures provide part of the solution, but the main benefits are lost if a trusted {+third+} party is still required to prevent [-doublespending.-] {+double-spending.+} We propose a solution to the double-spending problem using a [-peer-topeer-] {+peer-to-peer+} network. The network timestamps transactions by hashing them into an ongoing chain of hash-based proof-of-work, forming a record that cannot be changed without redoing the proof-of-work. The longest chain not only serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of CPU power. As long as [-honest nodes control the most-] {+a majority of+} CPU power [-on-] {+is controlled by nodes that are not cooperating to attack+} the network, [-they can-] {+they'll+} generate the longest chain and outpace [-any-] attackers. The network itself requires minimal structure. Messages are [-broadcasted-] {+broadcast+} on a best effort basis, and nodes can leave and rejoin the network at will, accepting the longest proof-of-work chain as proof of what happened while they were gone. ...The proof-of-work also solves the problem of determining representation in majority decision making. If the majority were based on one-IP-address-one-vote, it could be subverted by anyone able to allocate many IPs. Proof-of-work is essentially one-CPU-one-vote. The majority decision is represented by the longest chain, which has the greatest proof-of-work effort invested in it. If a majority of CPU power is controlled by honest nodes, the honest chain will grow the fastest and outpace any competing chains. To modify a past block, an attacker would have to redo the proof-of-work of the block and all blocks after it and then catch up with and surpass the work of the honest nodes. We will show later that the probability of a slower attacker catching up diminishes exponentially as subsequent blocks are added. {+To compensate for increasing hardware speed and varying interest in running nodes over time, the proof-of-work difficulty is determined by a moving average targeting an average number of blocks per hour. If they're generated too fast, the difficulty increases.+} ...New transactions are [-broadcasted-] {+broadcast+} to all nodes. Each node collects new transactions into a block. ...The steady addition of a constant of amount of new coins is analogous to gold miners expending resources to add gold to circulation. In our case, it is CPU time and electricity that is expended. The incentive [-may-] {+can+} also {+be funded with transaction fees. If the output value of a transaction is less than its input value, the difference is a transaction fee that is added to the incentive value of the block containing the transaction. Once a predetermined number of coins have entered circulation, the incentive can transition entirely to transaction fees and be completely inflation free. The incentive may+} help encourage nodes to stay honest. If a greedy attacker is able to assemble more CPU power than all the honest nodes, he would have to choose between using it to defraud people by stealing back his payments, or using it to generate new coins. He ought to find it more profitable to play by the rules, such rules that favour him with more new coins than everyone else combined, than to undermine the system and the validity of his own wealth. [-To compensate for increasing hardware speed and varying interest in running nodes over time, the proof-of-work difficulty is determined by a moving average targeting an average number of blocks per hour. If they're generated too fast, the difficulty increases.-] ...As such, the verification is reliable as long as honest nodes control the network, but is more vulnerable if the network is overpowered by an attacker. While network nodes can verify transactions for [-themselves and are only vulnerable to reversal,-] {+themselves,+} the simplified method can be fooled by an attacker's fabricated transactions for as long as the attacker can continue to overpower the network. One strategy to protect against this would be to accept alerts from network nodes when they detect an invalid block, prompting the user's software to download the full block and [-reported-] {+alerted+} transactions to confirm the inconsistency. Businesses that receive frequent payments will probably still want to run their own nodes for more independent security and quicker verification.
