Satoshi ↔ Dustin Trammell Correspondence
Dustin D. Trammell, a security researcher and cypherpunk using the handle “Druid,” was among the very first people to download and run the Bitcoin software after Satoshi announced it on the Cryptography Mailing List on January 9, 2009.
In this email dated January 11, 2009, Trammell wrote to Satoshi reporting on his experience with the alpha release. He mentioned that he was reading through the Bitcoin whitepaper and referenced the timestamp server section, sharing a link to publictimestamp.org as a potentially related resource.
Trammell reported that he had been running the software and had seen two “Generated” messages, but the credit field showed 0.00 and his balance had not changed. He asked whether this was related to a maturity requirement for newly generated coins.
This email initiated one of the earliest known private correspondences with Satoshi Nakamoto and established Trammell as one of Bitcoin’s very first users and miners. Trammell published the entirety of his email correspondence with Satoshi in November 2013.
Source: Published by Dustin Trammell in November 2013. The full correspondence is archived on the Bitcoin Wiki at en.bitcoin.it/wiki/Source:Trammell/Nakamoto_emails.
In this reply to Dustin Trammell, Satoshi thanked him for the timestamp service link and discussed alternative approaches. Regarding Trammell’s question about the credit field, Satoshi explained the coin maturity mechanism:
the credit field stays 0.00 until it matures, then it’ll be 50.00.
Satoshi asked Trammell whether it would be clearer to leave the credit field blank until maturity instead of displaying 0.00, showing his attention to usability in the earliest days of the software.
Satoshi recommended that Trammell upgrade to version 0.1.3, noting:
This version has really stabilized things.
This exchange reveals Satoshi’s responsiveness to early user feedback and his iterative approach to improving the software. Version 0.1.3 had fixed a communications bug that prevented nodes from properly broadcasting blocks to each other, which was critical for the network’s early functioning.
Source: Published by Dustin Trammell in November 2013. The full correspondence is archived on the Bitcoin Wiki at en.bitcoin.it/wiki/Source:Trammell/Nakamoto_emails.
In this reply to Satoshi, Trammell shared details about the proof-hashes Google Group he administered, offering it as a place for Bitcoin to post hash blocks:
It actually posts the hash blocks to a Google Group called ‘proof-hashes’, so similar result as if it were posting to Usenet. … Since I run that group, and it’s sole purpose is to archive proof-of-work hashes, feel free to join an account to have your system post there as well if you like.
On the credit field display question, Trammell preferred showing $0.00 over a blank field but noted his four generated coins all showed “unconfirmed.” He asked whether the existing transaction line would update upon maturity or generate a new credit transaction. He also confirmed he was unaware that double-clicking a transaction line showed details.
Trammell reported he had been running version 0.1.1 and would upgrade to 0.1.3, suggesting an auto-update feature. He expressed strong enthusiasm:
Electronic currency and cryptography are two things that I am very interested in so as you would assume I was drawn to this project immediately when I saw it posted to the Cryptography email list. Feel free to ping me for feedback or to test out new features, I’ll be happy to help out.
Source: Published by Dustin Trammell in November 2013. The full correspondence is archived on the Bitcoin Wiki at en.bitcoin.it/wiki/Source:Trammell/Nakamoto_emails.
Sent just eleven minutes after his previous email, Trammell reported two issues encountered during the upgrade from v0.1.0 to v0.1.3:
When closing my previous version (help said 0.1.1 but I think it was really 0.1.0), the process did not exit. The UI exited but the process remained. I had to manually kill the process before I was able to start version 0.1.3.
More concerning was the loss of his generated coins:
Upon opening version 0.1.3, all four of my transaction entries still say ‘unconfirmed’, but now the Descriptions say ‘Generated (not accepted)’. Does this mean that some other node had extended the chain first and my coins were generated in a dead branch? If so, why did the previous instance of the software not detect this immediately and begin generating coins in the winning branch? Bug in 0.1.0?
Trammell had correctly diagnosed the problem — the communications bug in v0.1.0 had prevented his node from broadcasting blocks to the network, causing all his mined blocks to be orphaned. Satoshi confirmed this in his next reply.
Source: Published by Dustin Trammell in November 2013. The full correspondence is archived on the Bitcoin Wiki at en.bitcoin.it/wiki/Source:Trammell/Nakamoto_emails.
In a separate email sent just nine minutes after reporting upgrade issues, Trammell raised what would become one of Bitcoin’s most enduring questions — mining centralization:
What prevents the single node with the most CPU power from generating and retaining the majority of the BitCoins? If every node is working independently of all others, if one is significantly more powerful than the others, isn’t it probable that this node will reach the proper conclusion before other nodes? An underpowered node may get lucky once in a while, but if they are at a significant horsepower advantage I would expect the majority of BitCoins to be generated by the most powerful node.
Satoshi’s reply the next day would explain that mining is not a race but a probabilistic lottery where each SHA-256 hash guess has an independent chance of success, and a computer’s share of coins is linearly proportional to its CPU power.
Source: Published by Dustin Trammell in November 2013. The full correspondence is archived on the Bitcoin Wiki at en.bitcoin.it/wiki/Source:Trammell/Nakamoto_emails.
In this email, Satoshi discussed a communications bug that had been fixed in version 0.1.3 which had prevented nodes from properly broadcasting blocks. He then offered to send Trammell some coins:
This is all fixed in 0.1.3. If you give me your IP, I’ll send you some coins.
This message is significant because it documents one of the very earliest direct Bitcoin transfers between individuals. Satoshi used the “send-to-IP” feature, which allowed coins to be sent directly to a node by connecting to its IP address. The receiving client would then provide a Bitcoin address for the transaction.
Trammell responded later that day (January 13, 2009, at 18:40 UTC) with his IP address:
I’m currently at 24.28.79.95, but that’s dynamic so it may change.
The following day, January 14, 2009 at 19:46 UTC, Satoshi sent Trammell 25.0 BTC in a single transaction (txid: d71fd2f64c0b34465b7518d240c00e83f6a5b10138a7079d1252858fe7e6b577). This transaction was sent from address 1Jhk2DHosaaZx1E4CbnTGcKM7FC88YHYv9 to Trammell’s address 1DCbY2GYVaAMCBpuBNN5GVg3a47pNK1wdi.
Their subsequent correspondence also touched on the insecurities of sending bitcoin by IP address. Satoshi ultimately dropped the send-to-IP feature from the software entirely, partly informed by these discussions.
Source: Published by Dustin Trammell in November 2013. The full correspondence is archived on the Bitcoin Wiki at en.bitcoin.it/wiki/Source:Trammell/Nakamoto_emails. Transaction details documented on Trammell’s blog.
Trammell responded to several points from Satoshi’s comprehensive reply. He explained the proof-hashes Google Group required no membership to post — simply emailing proof-hashes@googlegroups.com would publish the content. He suggested that the Bitcoin client could post the current block chain every 10,000 blocks as supplemental documentation.
On Bitcoin’s value proposition, Trammell identified the core challenge early:
Yea, that was the primary feature that caught my eye. The real trick will be to get people to actually value the BitCoins so that they become currency. Currently, they’re just collections of bits…
Trammell then provided his IP address for Satoshi’s offered coin transfer:
I’m currently at 24.28.79.95, but that’s dynamic so it may change.
This IP address was used the following day (January 14, 2009) when Satoshi sent Trammell 25.0 BTC — one of the earliest known person-to-person Bitcoin transactions.
On the mining explanation, Trammell coined a vivid analogy:
Ahh I see… So each guess is like the spin of a roulette wheel, completely independent from all other guesses and the extra CPU power just translates to more successful guesses than anyone else. Unfortunately my ability to understand complex mathematics is conversely proportional to how interested I am in cryptography (:
Source: Published by Dustin Trammell in November 2013. The full correspondence is archived on the Bitcoin Wiki at en.bitcoin.it/wiki/Source:Trammell/Nakamoto_emails.
In a new email thread, Trammell — a professional security researcher — reported on his detailed analysis of Bitcoin’s network protocol. He had captured and analyzed packet traces during a transaction he sent to himself, observing that the protocol transmitted some cleartext information including transaction names and comments.
Trammell then presented a thorough security analysis of the send-to-IP feature, identifying its fundamental vulnerability to man-in-the-middle attacks:
In the case of the IP transaction, the BitCoin client seems to trust that the IP that it has connected to really is the intended recipient of the transaction. It is fairly trivial to launch a man-in-the-middle attack and steal incoming transactions.
He described a concrete attack scenario involving ARP poisoning on a local LAN, and noted the vulnerability extended to any hop along the network route, including ISP administrators.
Trammell’s recommendation was clear:
I would recommend not allowing the use of network addresses as the address of an intended recipient. I would think it would be a bit more secure to always require a BitCoin address and do transactions that way.
He also proposed an alternative: a network-based resolution service where nodes could look up the IP address associated with a Bitcoin address, using the key pairs already in place for authentication.
This email is significant as one of the earliest security audits of the Bitcoin software. The send-to-IP feature was eventually removed from Bitcoin, partly informed by security concerns like those raised by Trammell.
Source: Published by Dustin Trammell in November 2013. The full correspondence is archived on the Bitcoin Wiki at en.bitcoin.it/wiki/Source:Trammell/Nakamoto_emails.
In this email, Satoshi noted that at least one node on the network had a frequently changing IP address within the same class B range, which he hadn’t anticipated. He asked Trammell’s permission to CC the conversation to bitcoin-list or the Cryptography mailing list, and shared the bitcoin-list subscription details.
Satoshi then referenced Hal Finney’s earlier suggestion about Bitcoin as an investment:
Hal sort of alluded to the possibility that it could be seen as a long-odds investment. I would be surprised if 10 years from now we’re not using electronic currency in some way, now that we know a way to do it that won’t inevitably get dumbed down when the TTP gets cold feet.
He outlined several potential use cases for Bitcoin, even if it didn’t gain immediate mainstream adoption:
Even if it doesn’t take off straight away, it’s now available for use by the next guy who comes up with a plan that needs some kind of token or electronic currency. It could get started in a closed system or narrow niche like reward points, donation tokens, currency for a game or micropayments for adult sites. Once it gets bootstrapped, there are so many applications if you could effortlessly pay a few cents to a website as easily as dropping coins in a vending machine.
Satoshi described Bitcoin’s pay-to-send email feature as an existing use case, envisioning that famous people could accept bitcoin payments to read fan messages, and subscription sites could charge bitcoins for free trials to prevent abuse.
This email is the draft of what would later be CC’d to the bitcoin-list and Cryptography mailing lists as a public message on January 16-17, 2009.
Source: Published by Dustin Trammell in November 2013. The full correspondence is archived on the Bitcoin Wiki at en.bitcoin.it/wiki/Source:Trammell/Nakamoto_emails.
Responding to Trammell’s detailed MITM analysis, Satoshi introduced a classification framework for attacks that would become influential in security thinking about Bitcoin:
I group attacks into two classes:
- Attacks that can only be done by someone actually in the chain of communication
- Attacks that can be done by anyone on the Internet from anywhere
Satoshi explained that Type 1 attacks affect people on the same LAN or ISP route, while Type 2 exposes users to billions of potential attackers who can achieve economies of scale. He acknowledged the send-to-IP vulnerability:
Sending by IP requests a new public key, so yes, it’s vulnerable to type 1 man-in-the-middle. If that’s a concern, sending to a Bitcoin address doesn’t have that vulnerability, although there’s a small privacy tradeoff.
He noted pragmatically that most people would obtain Bitcoin addresses from non-SSL websites or unsigned email, which was already vulnerable to both attack types through DNS poisoning.
Satoshi proposed a combined approach for the future:
One solution would be to use both the IP and Bitcoin addresses when sending (maybe 1.2.3.4-1Kn8iojk…), where the recipient uses the public key of the Bitcoin address to sign the new public key to prove that you’re sending to who you think you are.
He also confirmed that sending to a Bitcoin address worked by computing the transaction into the blockchain for the recipient to discover, and mentioned wallet encryption as a future feature.
Source: Published by Dustin Trammell in November 2013. The full correspondence is archived on the Bitcoin Wiki at en.bitcoin.it/wiki/Source:Trammell/Nakamoto_emails.
Trammell continued the security discussion, arguing that Bitcoin addresses had an advantage over IP-based sending because they could be verified through multiple independent channels:
True, but the upside to using the BitCoin address is that two people can communicate via a number of different channels to verify the address. If my friend gets my address off my website, and thinks something fishy is going on, he can call me, or IM me, or email me, etc. to verify the address. An attacker would then have to basically be replacing my address with the malicious one in every possible communications channel, including voice, which is a difficult feat.
He endorsed Satoshi’s proposed combined IP+Bitcoin address solution, noting that regular transacting parties would already have each other’s Bitcoin addresses in their address books.
Trammell then raised an important concern about data loss — one of the earliest discussions of wallet backup:
One thing that came to mind on this topic is the potential for BitCoin loss if you have a system failure. The application doesn’t seem to store any data in the directory that it runs in, so I assume it’s stored in the registry and other places … so it may be a good idea to have the application be able to export everything that it needs for recovery to a file that could be backed up off of the system.
He also proposed an optional “Advertise my BitCoin address to the network” toggle as a privacy-preserving way to enable address resolution, and reported that the application wasn’t cleanly closing its network sockets on exit (TCP RSTs).
Source: Published by Dustin Trammell in November 2013. The full correspondence is archived on the Bitcoin Wiki at en.bitcoin.it/wiki/Source:Trammell/Nakamoto_emails.
Trammell responded to Satoshi’s request to CC the conversation publicly, confirming that the node with the changing IP was not him — his Bitcoin client at work used a static NAT address and his home IP had been stable for at least three days of testing transfers between the two.
He agreed to have the conversation shared publicly and subscribed to bitcoin-list immediately. Trammell then revealed his investment-minded motivation for early mining, prompted by Hal Finney’s public message:
Yes, I saw that message and was one of the other reasons I started up a node so quickly. My systems aren’t doing much of anything else while idle, so why not create BitCoins? And if they’re worth something someday…? Bonus!
On Satoshi’s micropayment use cases, Trammell raised a practical adoption barrier:
I can see how various types of sites that have a need for micropayments could use them, however I also see an impedement to adoption if they want to use an existing BitCoin peer group rather than a closed system since they would first have to generate enough coins to support what they intend to do (or buy them from someone else). A closed system obviously doesn’t have that problem.
This is notable as one of the earliest discussions of the Bitcoin bootstrapping problem — how to get enough liquidity into circulation for the system to function as a medium of exchange.
Source: Published by Dustin Trammell in November 2013. The full correspondence is archived on the Bitcoin Wiki at en.bitcoin.it/wiki/Source:Trammell/Nakamoto_emails.
This email was CC’d to both bitcoin-list@lists.sourceforge.net and the Cryptography mailing list at metzdowd.com, making it a public message. It was a polished version of Satoshi’s earlier private email to Trammell (threadPosition 9), with some content reorganized and a key addition.
Satoshi quoted Trammell’s earlier observation about valuing bitcoins and shared his vision:
I would be surprised if 10 years from now we’re not using electronic currency in some way, now that we know a way to do it that won’t inevitably get dumbed down when the trusted third party gets cold feet.
He described Bitcoin’s potential in niche applications — reward points, donation tokens, game currency, micropayments, and proof-of-work applications. He reiterated the pay-to-send email concept and subscription trial use cases.
The email contains what became one of Satoshi’s most famous lines:
It might make sense just to get some in case it catches on. If enough people think the same way, that becomes a self fulfilling prophecy. Once it gets bootstrapped, there are so many applications if you could effortlessly pay a few cents to a website as easily as dropping coins in a vending machine.
This public email, originating from Satoshi’s private correspondence with Trammell, became one of the most frequently cited Satoshi writings in Bitcoin history.
Source: Published by Dustin Trammell in November 2013. Also archived on the Cryptography mailing list and bitcoin-list. The full private correspondence is on the Bitcoin Wiki at en.bitcoin.it/wiki/Source:Trammell/Nakamoto_emails.
Responding to Trammell’s concerns about data loss and wallet backup, Satoshi disclosed the wallet’s storage location and technology:
The files are in “%appdata%\Bitcoin”, that’s the directory to backup. The data is stored in a transactional database DBM, so it should be safe from loss if there’s a crash or power failure.
He noted that %appdata% was the per-user directory that modern programs like Firefox used for settings, despite Microsoft changing its name with every Windows release, being full of spaces, and running off the screen.
Regarding the unclean socket closure Trammell had reported:
Just now added code to the next release for that.
This brief exchange demonstrates Satoshi’s rapid development cycle in Bitcoin’s earliest days — Trammell reported a bug and Satoshi had already coded a fix by the time he replied. The DBM (Berkeley DB) database choice would later prove significant when a database lock limit issue caused a chain fork in March 2013.
Source: Published by Dustin Trammell in November 2013. The full correspondence is archived on the Bitcoin Wiki at en.bitcoin.it/wiki/Source:Trammell/Nakamoto_emails.
Trammell initiated a new email thread about a puzzling transaction. He had sent himself 100 BTC from his work Bitcoin client to his home client using a Bitcoin address (rather than by IP), but the transaction details showed an unexpected label:
After that first transfer of 25.00, you didn’t send me another 100.00 did you? I sent myself 100.00 from my BitCoin application at work to my one at home using the BitCoin address rather than by IP. My application at home has a 100.00 transfer received, however it’s transaction details say “Received with: Satoshi 12higDjoCCNXSA95xZMWUdPvXNmkAduhWv”. That is not my BitCoin address from work, so I assume this means that I received the payment encoded with a block that was computed by your client?
Trammell didn’t recognize the Bitcoin address shown and wondered how the software knew Satoshi’s name, since he didn’t recall ever entering a name in the application. This confusion highlighted early usability issues with Bitcoin’s address book and transaction display that Satoshi would address in his reply.
Source: Published by Dustin Trammell in November 2013. The full correspondence is archived on the Bitcoin Wiki at en.bitcoin.it/wiki/Source:Trammell/Nakamoto_emails.
Satoshi clarified the confusion about Trammell’s transaction display. The address shown was actually one of Trammell’s own receiving addresses, not Satoshi’s:
It should be your Bitcoin address at home that you received it with. There’s no way for it to know who it’s from, so the best it can do is tell which of your addresses it was received on. You can create multiple addresses and give a different address to each person and label them to help figure out who’s sending to you.
He explained the address book labeling system:
It doesn’t know any names other than what you tell it. The name printed there is what’s associated in your address book for that address, either under the Address Book button or the “Change…” button to the right of your Bitcoin address.
This email contains one of the earliest explanations of Bitcoin’s pseudonymous nature — the protocol has no concept of sender identity, and the best practice for identifying payers is to create unique receiving addresses for each counterparty. This concept would become fundamental to Bitcoin privacy best practices.
Source: Published by Dustin Trammell in November 2013. The full correspondence is archived on the Bitcoin Wiki at en.bitcoin.it/wiki/Source:Trammell/Nakamoto_emails.
Trammell had his “aha” moment about the confusing transaction label:
Ah! I didn’t even notice it was my address at home, you’re right (: I do have multiple addresses created at home so I didn’t make the connection.
He confirmed that ‘Satoshi’ was indeed associated with the receiving address under the Change button’s addresses, but raised a new question:
I don’t recall setting that value though, is that the default or something? (this is the first, default, address that the application generated itself when I first ran it)
This exchange highlights the early usability challenges of Bitcoin — even a technically sophisticated user like Trammell, who was a security researcher comfortable with cryptographic concepts, found the address book and transaction display confusing enough to misidentify the source of his own self-transfer.
Source: Published by Dustin Trammell in November 2013. The full correspondence is archived on the Bitcoin Wiki at en.bitcoin.it/wiki/Source:Trammell/Nakamoto_emails.
Satoshi clarified that the default label for a new address was “Your Address,” not “Satoshi.” He suggested Trammell had likely mislabeled his own address while trying to label what he thought was Satoshi’s address:
The first default one is labelled “Your Address” when it’s created.
All the places where address book labels are set are where the user manually sets it. The only time it automatically adds a label is a blank one when you send to a new address. I guess you could have entered the label on an address you thought was mine but the software was confusing and you put it in the wrong place.
Satoshi then offered a candid acknowledgment of Bitcoin’s UX limitations:
Address book labels for receiving addresses is confusing but I’m not sure what else to do. Anyone using it for more than just simple purposes would need to create different receiving addresses for each payer so they could tell who’s paying them. That concept doesn’t have much analogy in the real world.
This is a revealing admission from Satoshi about one of Bitcoin’s most persistent usability challenges — the concept of generating unique addresses per payer was fundamentally new and had no equivalent in traditional financial systems that users could draw upon for intuitive understanding.
Source: Published by Dustin Trammell in November 2013. The full correspondence is archived on the Bitcoin Wiki at en.bitcoin.it/wiki/Source:Trammell/Nakamoto_emails.
In the final email of the Bitcoin Transfer sub-thread, Trammell accepted that the mislabeling was his own mistake and offered a concrete UI improvement suggestion:
I think had it said “Received with address: X” rather than just “Received with: X” I think I would have understood, although I’m sure that address being mislabeled ‘Satoshi’ was the primary reason for my initial confusion.
He also identified the closest real-world analogy for Bitcoin’s multiple receiving addresses:
You’re right though, there’s really nothing comparable in the current financial system that people are used to other than maybe being able to use multiple recipient email addresses for PayPal. Perhaps it could say “Received payment to: X”?
This final exchange in the sub-thread shows the collaborative nature of early Bitcoin development, where real user feedback directly informed UI improvements. Trammell’s suggestion to add “address” or “payment to” in the display text addressed the ambiguity between “who sent this” and “which of my addresses received this” — a distinction that remains relevant in Bitcoin wallet design.
Source: Published by Dustin Trammell in November 2013. The full correspondence is archived on the Bitcoin Wiki at en.bitcoin.it/wiki/Source:Trammell/Nakamoto_emails.
In the final email of the Satoshi-Trammell correspondence, sent nearly a week after the previous exchange, Satoshi discussed the economics of spam in a system where proof-of-work tokens have value. He quoted Hal Finney’s observation that valuable POW tokens would make botnet infections more noticeable to computer owners.
Satoshi then proposed a novel economic counter-mechanism — “reverse-spamming”:
Another factor that would mitigate spam if POW tokens have value: there would be a profit motive for people to set up massive quantities of fake e-mail accounts to harvest POW tokens from spam. They’d essentially be reverse-spamming the spammers with automated mailboxes that collect their POW and don’t read the message. The ratio of fake mailboxes to real people could become too high for spam to be cost effective.
He noted this process could paradoxically help establish the token’s value:
The process has the potential to establish the POW token’s value in the first place, since spammers that don’t have a botnet could buy tokens from harvesters. While the buying back would temporarily let more spam through, it would only hasten the self-defeating cycle leading to too many harvesters exploiting the spammers.
Satoshi also drew a parallel to existing systems, noting that e-gold already experienced a form of spam called “dusting” where spammers sent tiny amounts of gold dust to include messages in transaction comment fields. He suggested a configurable minimum payment threshold as a solution.
This email represents some of Satoshi’s most creative economic thinking, applying game theory to spam economics and showing how market forces could naturally mitigate abuse in a proof-of-work system.
Source: Published by Dustin Trammell in November 2013. The full correspondence is archived on the Bitcoin Wiki at en.bitcoin.it/wiki/Source:Trammell/Nakamoto_emails.