diff --git a/docs/emails/cryptography/15.md b/docs/emails/cryptography/15.md
new file mode 100644
index 0000000..947c275
--- /dev/null
+++ b/docs/emails/cryptography/15.md
@@ -0,0 +1,70 @@
+---
+layout: default
+title: Bitcoin P2P e-cash paper
+grand_parent: Emails
+parent: Cryptography Mailing List
+nav_order: 15
+---
+
+# Bitcoin P2P e-cash paper
+
+The email on the Cryptography Mailing List that announced Bitcoin publicly to the world.
+{: .fs-6 .fw-300 } 
+
+---
+
+```
+James A. Donald wrote:
+> > Fortunately, it's only necessary to keep a
+> > pending-transaction pool for the current best branch.
+>
+> This requires that we know, that is to say an honest
+> well behaved peer whose communications and data storage
+> is working well knows, what the current best branch is -
+
+I mean a node only needs the pending-tx pool for the best branch it
+has. The branch that it currently thinks is the best branch.
+That's the branch it'll be trying to make a block out of, which is
+all it needs the pool for.
+
+
+> > Broadcasts will probably be almost completely
+> > reliable.
+>
+> Rather than assuming that each message arrives at least
+> once, we have to make a mechanism such that the
+> information arrives even though conveyed by messages
+> that frequently fail to arrive.
+
+I think I've got the peer networking broadcast mechanism covered.
+
+Each node sends its neighbours an inventory list of hashes of the
+new blocks and transactions it has. The neighbours request the
+items they don't have yet. If the item never comes through after a
+timeout, they request it from another neighbour that had it. Since
+all or most of the neighbours should eventually have each item,
+even if the coms get fumbled up with one, they can get it from any
+of the others, trying one at a time.
+
+The inventory-request-data scheme introduces a little latency, but
+it ultimately helps speed more by keeping extra data blocks off the
+transmit queues and conserving bandwidth.
+
+
+> You have an outline
+> and proposal for such a design, which is a big step
+> forward, but the devil is in the little details.
+
+I believe I've worked through all those little details over the
+last year and a half while coding it, and there were a lot of them.
+The functional details are not covered in the paper, but the
+sourcecode is coming soon. I sent you the main files.
+(available by request at the moment, full release soon)
+
+Satoshi Nakamoto
+
+
+---------------------------------------------------------------------
+The Cryptography Mailing List
+Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
+```