From [email protected] Thu Jan 15 19:46:35 2009
Return-Path: <[email protected]>
Delivered-To: [email protected]
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" <[email protected]>
Reply-To: [email protected]
To: [email protected]
Message-ID: <CHILKAT-MID-c7513ad6-448b-8470-f92b-ff663d9fd33b@server123>
X-Evolution-Source: pop://[email protected]/
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