From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UZOZV-0005x3-U2 for bitcoin-development@lists.sourceforge.net; Mon, 06 May 2013 16:47:29 +0000 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; Received: from mail-ob0-f176.google.com ([209.85.214.176]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UZOZU-0005gB-21 for bitcoin-development@lists.sourceforge.net; Mon, 06 May 2013 16:47:29 +0000 Received: by mail-ob0-f176.google.com with SMTP id er7so3265553obc.35 for ; Mon, 06 May 2013 09:47:22 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.40.129 with SMTP id x1mr5755085obk.15.1367858842695; Mon, 06 May 2013 09:47:22 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.167.169 with HTTP; Mon, 6 May 2013 09:47:22 -0700 (PDT) In-Reply-To: <20130506163732.GB5193@petertodd.org> References: <20130506161216.GA5193@petertodd.org> <20130506163732.GB5193@petertodd.org> Date: Mon, 6 May 2013 18:47:22 +0200 X-Google-Sender-Auth: IQUb8ihUli5J1bN1_xV6MqpLesk Message-ID: From: Mike Hearn To: Peter Todd Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -1.5 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1UZOZU-0005gB-21 Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes) X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 16:47:30 -0000 > 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.