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-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UZP50-0007CH-MN for bitcoin-development@lists.sourceforge.net; Mon, 06 May 2013 17:20:02 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.148.161 as permitted sender) client-ip=62.13.148.161; envelope-from=pete@petertodd.org; helo=outmail148161.authsmtp.com; Received: from outmail148161.authsmtp.com ([62.13.148.161]) by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1UZP4u-0007bG-3j for bitcoin-development@lists.sourceforge.net; Mon, 06 May 2013 17:20:02 +0000 Received: from mail-c233.authsmtp.com (mail-c233.authsmtp.com [62.13.128.233]) by punt6.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id r46HJmpS063838; Mon, 6 May 2013 18:19:48 +0100 (BST) Received: from petertodd.org (petertodd.org [174.129.28.249]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r46HJhTx048787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 6 May 2013 18:19:45 +0100 (BST) Date: Mon, 6 May 2013 13:19:43 -0400 From: Peter Todd To: Mike Hearn Message-ID: <20130506171943.GA22505@petertodd.org> References: <20130506161216.GA5193@petertodd.org> <20130506163732.GB5193@petertodd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wRRV7LY7NUeQGEoC" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 2641539b-b671-11e2-a49c-0025907707a1 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdgQUFVQNAgsB AmUbWlxeUVR7XWU7 ag1VcwRfa1RMVxto VEFWR1pVCwQmQxgH fmRGNlFycw1BcHk+ ZEBnWnAVXkJ+dEN+ SxxJR2sBZHphaTUd TRFcflBJcANIexZF bVd/UyIMLwdSbGoL NQ4vNDcwO3BTJTpY RgYVKF8UXXNDMj8n TBccEC8+WkQJSz97 NxUtKVMABw5RLUwp YxMaVEgGMhQfQgdf A1ovSCFePREZXTct AA8SW0kSHSYcKQAA X-Authentic-SMTP: 61633532353630.1021:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 174.129.28.249/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. 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 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1UZP4u-0007bG-3j 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 17:20:02 -0000 --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 06, 2013 at 06:47:22PM +0200, Mike Hearn wrote: > 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. You mean scam you with a zero-conf transaction that hasn't actually been broadcast? You know how I feel about zero-conf. > 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. We already depend on OpenSSL, why not just use standard SSL? Define a per-node compressed pubkey to pass around, and then do whatever is easiest to get the actual SSL up and running. If we have to use that pubkey to in-turn sign for a secondary RSA key or whatever due to compatibility, no big deal. Define a new service bit SSL and if you connect to a SSL supporting node switch to SSL within the same TCP connection. > 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). Obfusication probably isn't the hard part, it's SPV bloom filter privacy that is the tough one, but probably a problem better handled by Tor. > 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. For phone stuff you should work with The Guardian Project - they've implemented Tor on Android among other things and want to find easier ways for apps to use it. --=20 'peter'[:-1]@petertodd.org 000000000000014671272e3a4dd966bb56d4a9a27751b5cd4dc75dc931660cb5 --wRRV7LY7NUeQGEoC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlGH5i8ACgkQpEFN739thoyx1gCfUg4H9Fqya4cx9PURSWrn+5dD MbcAoIGlp0BNtznKD4HiCJwYKqTk/42y =w4zb -----END PGP SIGNATURE----- --wRRV7LY7NUeQGEoC--