Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.214.176 as permitted sender)
	client-ip=209.85.214.176; envelope-from=mh.in.england@gmail.com;
	helo=mail-ob0-f176.google.com; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
In-Reply-To: <20130506163732.GB5193@petertodd.org>
References: <CANEZrP1YFCLmasOrdxdKDP1=x8nKuy06kGRqZwpnmnhe3-AroA@mail.gmail.com>
	<20130506161216.GA5193@petertodd.org>
	<CA+8xBpfdY7GsQiyrHuOG-MqXon0RGShpg2Yv-KeAXQ-503kAsA@mail.gmail.com>
	<20130506163732.GB5193@petertodd.org>
Date: Mon, 6 May 2013 18:47:22 +0200
Message-ID: <CANEZrP2WqXZVRJp6ag=RC4mSkt+a6qTYYpvE=DW_0Rdr=_BBHA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Peter Todd <pete@petertodd.org>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Discovery/addr packets (was: Service bits
 for pruned nodes)
Precedence: list

> Speaking of, off-topic for this discussion, but in the future
> node-to-node communicate should be encrypted and signed

Yes, I'd like to do this. The threat isn't really ISPs which are
mostly trustable (the worst they normally do outside of places like
China is dick about with ads), the big threat is people who use
untrusted WiFi without realising and end up thinking they received
money when actually they were just connected to a hotspot running in
the attackers pocket. I'm rather expecting that kind of thing to
happen in future.

I think we can converge on the best solution with several iterations:

Iteration 1) Make it clear in the UI that if the phone is connected to
WiFi, payments from untrusted people should not be accepted. Currently
the Android app merely says the money won't be spendable for a few
minutes. It needs to communicate the "may not exist" aspect more
clearly. If you're connected via a cell tower, the existing wording is
fine - it's very unlikely your telco is trying to scam you in a
person-to-person transaction, traffic is encrypted and 3G+ connections
authenticate the network so you can't be MITMd except by your telco.
Assuming you have a good list of IPs, of course.

Iteration 2) Give nodes keys that appear in addr broadcasts and seed
data (whether it be via https or otherwise), and have each node keep a
running hash of all messages sent on a connection so far. Add a new
protocol message that asks the node to sign the current accumulated
hash. Not all messages really need to be signed, eg asking for
signatures of blocks is sort of pointless at high difficulty levels
because the structures are self proving and a simple watchdog timer
that looks for unusually slow progress is probably enough. If the
client keeps the same accumulated hash then when you encounter
something you care about the accuracy of, you can ask for a signature
over all traffic so far.

Iteration 3) Do something about end to end encryption, just delegate
everything to Tor, or find some other way to obfuscate the origin of a
transaction (a mini onion network for example).

Last time I looked, Tor wasn't really usable in library form and
connecting to hidden services is really slow. So it'd be an issue to
just re-use it out of the box, I think.