diff --git a/docs/emails/dustin-trammel/4.md b/docs/emails/dustin-trammel/4.md new file mode 100644 index 0000000..85754b2 --- /dev/null +++ b/docs/emails/dustin-trammel/4.md @@ -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: +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" +Reply-To: satoshi@vistomail.com +To: dtrammell@dustintrammell.com +Message-ID: +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 +```