diff --git a/docs/emails/cryptography/14.md b/docs/emails/cryptography/14.md
new file mode 100644
index 0000000..2698801
--- /dev/null
+++ b/docs/emails/cryptography/14.md
@@ -0,0 +1,110 @@
+---
+layout: default
+title: Bitcoin P2P e-cash paper
+grand_parent: Emails
+parent: Cryptography Mailing List
+nav_order: 14
+---
+
+# Bitcoin P2P e-cash paper
+
+The email on the Cryptography Mailing List that announced Bitcoin publicly to the world.
+{: .fs-6 .fw-300 } 
+
+---
+
+```
+Ray Dillinger wrote:
+> One way to do this would be
+> to have the person recieving the coin generate an asymmetric
+> key pair, and then have half of it published with the
+> transaction. In order to spend the coin later, s/he must
+> demonstrate posession of the other half of the asymmetric
+> key pair, probably by using it to sign the key provided by
+> the new seller.
+
+Right, it's ECC digital signatures. A new key pair is used for every
+transaction.
+
+It's not pseudonymous in the sense of nyms identifying people, but it
+is at least a little pseudonymous in that the next action on a coin
+can be identified as being from the owner of that coin.
+
+
+> Mmmm. I don't know if I'm comfortable with that. You're saying
+> there's no effort to identify and exclude nodes that don't
+> cooperate? I suspect this will lead to trouble and possible DOS
+> attacks.
+
+There is no reliance on identifying anyone. As you've said, it's
+futile and can be trivially defeated with sock puppets.
+
+The credential that establishes someone as real is the ability to
+supply CPU power.
+
+
+> Until.... until what? How does anybody know when a transaction
+> has become irrevocable? Is "a few" blocks three? Thirty? A
+> hundred? Does it depend on the number of nodes? Is it logarithmic
+> or linear in number of nodes?
+
+Section 11 calculates the worst case under attack. Typically, 5 or
+10 blocks is enough for that. If you're selling something that
+doesn't merit a network-scale attack to steal it, in practice you
+could cut it closer.
+
+
+> But in the absence of identity, there's no downside to them
+> if spends become invalid, if they've already received the
+> goods they double-spent for (access to website, download,
+> whatever). The merchants are left holding the bag with
+> "invalid" coins, unless they wait that magical "few blocks"
+> (and how can they know how many?) before treating the spender
+> as having paid.
+>
+> The consumers won't do this if they spend their coin and it takes
+> an hour to clear before they can do what they spent their coin on.
+> The merchants won't do it if there's no way to charge back a
+> customer when they find the that their coin is invalid because
+> the customer has doublespent.
+
+This is a version 2 problem that I believe can be solved fairly
+satisfactorily for most applications.
+
+The race is to spread your transaction on the network first. Think 6
+degrees of freedom -- it spreads exponentially. It would only take
+something like 2 minutes for a transaction to spread widely enough
+that a competitor starting late would have little chance of grabbing
+very many nodes before the first one is overtaking the whole network.
+During those 2 minutes, the merchant's nodes can be watching for a
+double-spent transaction. The double-spender would not be able to
+blast his alternate transaction out to the world without the merchant
+getting it, so he has to wait before starting.
+
+If the real transaction reaches 90% and the double-spent tx reaches
+10%, the double-spender only gets a 10% chance of not paying, and 90%
+chance his money gets spent. For almost any type of goods, that's
+not going to be worth it for the scammer.
+
+Information based goods like access to website or downloads are
+non-fencible. Nobody is going to be able to make a living off
+stealing access to websites or downloads. They can go to the file
+sharing networks to steal that. Most instant-access products aren't
+going to have a huge incentive to steal.
+
+If a merchant actually has a problem with theft, they can make the
+customer wait 2 minutes, or wait for something in e-mail, which many
+already do. If they really want to optimize, and it's a large
+download, they could cancel the download in the middle if the
+transaction comes back double-spent. If it's website access,
+typically it wouldn't be a big deal to let the customer have access
+for 5 minutes and then cut off access if it's rejected. Many such
+sites have a free trial anyway.
+
+Satoshi Nakamoto
+
+
+---------------------------------------------------------------------
+The Cryptography Mailing List
+Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
+```