Create 4.md

2021-01-02 00:24:13 -06:00
parent ec0adee90d
commit 34731991af
1 changed files with 90 additions and 0 deletions
@@ -0,0 +1,90 @@
+---
+layout: default
+title: 'Re: A few thoughts...'
+date: 2009-01-15 19:46:35
+grand_parent: Emails
+parent: Dustin Trammel
+nav_order: 4
+---
+
+# Re: A few thoughts...
+
+The email on the Cryptography Mailing List that announced Bitcoin publicly to the world.
+{: .fs-6 .fw-300 } 
+
+---
+
+```
+From satoshi@vistomail.com Thu Jan 15 19:46:35 2009
+Return-Path: <satoshi@vistomail.com>
+Delivered-To: dustintrammell-dtrammell@dustintrammell.com
+Received: (qmail 17744 invoked from network); 15 Jan 2009 19:46:35 -0000
+Received: from anonymousspeech.com (HELO mail.anonymousspeech.com)
+ (124.217.253.42) by oaklabs.net with SMTP; 15 Jan 2009 19:46:35 -0000
+Received: from server123 ([124.217.253.42]) by anonymousspeech.com with
+ MailEnable ESMTP; Fri, 16 Jan 2009 03:46:30 +0800
+MIME-Version: 1.0
+Date: Fri, 16 Jan 2009 03:42:00 +0800
+X-Mailer: Chilkat Software Inc (http://www.chilkatsoft.com)
+X-Priority: 3 (Normal)
+Subject: Re: A few thoughts...
+Content-Type: text/plain
+From: "Satoshi Nakamoto" <satoshi@vistomail.com>
+Reply-To: satoshi@vistomail.com
+To: dtrammell@dustintrammell.com
+Message-ID: <CHILKAT-MID-c7513ad6-448b-8470-f92b-ff663d9fd33b@server123>
+X-Evolution-Source: pop://dustintrammell-dtrammell@mail.oaklabs.net/
+Content-Transfer-Encoding: 8bit
+
+I group attacks into two classes:
+1) Attacks that can only be done by someone actually in the chain
+    of communication
+2) Attacks that can be done by anyone on the Internet from anywhere
+
+Type 1 exposes you to people in your house or company on your
+local LAN, admins at ISPs in between, and the LAN on the
+recipient's side.  Type 2 exposes you to a billion people who can
+self-select to be attackers and get economy of scale when they
+develop one technique to attack multiple victims.
+
+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.  I have a feeling most of the time
+people will get Bitcoin addresses off of non-SSL websites and
+unsigned cleartext e-mail, which is already vulnerable to type 1
+and type 2 through DNS poisoning.
+
+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.  If the
+system starts to be used for real business purposes, I will
+certainly implement that.  Another solution is to use SSL.
+
+For now, it's pretty obvious that if you send to an IP, you didn't
+give any other identifying information about the recipient, so
+you're blindly sending to whoever answers that IP.
+
+Another feature for later is an option to encrypt your wallet.
+ 
+> If I understand how that is done correctly, you just compute the
+> transaction into the block chain and let the intended recipient
+> 'discover' it, correct? 
+
+That's correct.
+
+> An alternative could be to allow the network
+> nodes to provide a resolution service, where they ask around for the
+> network address of a BitCoin address, and if that node is online, once a
+> consensus is agreed upon by the network for that address the sending
+> BitCoin application connects directly there.
+
+It would be nice to only need the Bitcoin address and have the IP
+worked out behind the scenes.  Might have privacy or denial of
+service issues.  Certainly before another sending method is
+implemented, there's plenty of time now to fully think through the
+design and make sure it's the best way.
+
+Satoshi
+```