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 1Uzo6e-00042S-Ah for bitcoin-development@lists.sourceforge.net; Thu, 18 Jul 2013 13:18:52 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.149.84 as permitted sender) client-ip=62.13.149.84; envelope-from=pete@petertodd.org; helo=outmail149084.authsmtp.net; Received: from outmail149084.authsmtp.net ([62.13.149.84]) by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1Uzo6c-0001QQ-EA for bitcoin-development@lists.sourceforge.net; Thu, 18 Jul 2013 13:18:52 +0000 Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232]) by punt8.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id r6IDIhqe029063; Thu, 18 Jul 2013 14:18:43 +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 r6IDIajG075329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 18 Jul 2013 14:18:39 +0100 (BST) Date: Thu, 18 Jul 2013 09:18:36 -0400 From: Peter Todd To: Mike Hearn Message-ID: <20130718131836.GA28234@petertodd.org> References: <2BDA0943-22BB-4405-9AF0-86FB41FD04A6@include7.ch> <2F20A509-13A9-4C84-86D7-A15C21BACD53@include7.ch> <2A1C412D-414E-4C41-8E20-F0D21F801328@grabhive.com> <8EE501AA-1601-4C28-A32E-80F17D219D3A@grabhive.com> <20130717105853.GA10083@savin> <20130718121307.GA6062@savin> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fUYQa+Pmc3FrFX/N" Content-Disposition: inline In-Reply-To: <20130718121307.GA6062@savin> User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 8fa601d6-efac-11e2-b10b-0025903375e2 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdwoUEkAYAgsB AmUbWlBeUVV7Wmo7 ag1VcwRfa1RMVxto VEFWR1pVCwQmQxp4 cmdPCG5ycABFenc+ ZEZqXnkVVBIrc0Z8 FkhJQDtXNnphaTUd TRJZd1FJcANIexZF aVN4USYPLwdSbGoL NQ4vNDcwO3BTJTpY RgYVKF8UXXNDJQYC DxoDAT4oHEsJEG1z MBU9eBY9GloLNUkv OlonVjBQGR4OAQpf GWJMHGlXPVAESjUs FwAbNQAA X-Authentic-SMTP: 61633532353630.1019: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: 1Uzo6c-0001QQ-EA Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] SPV bitcoind? (was: Introducing BitcoinKit.framework) 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: Thu, 18 Jul 2013 13:18:52 -0000 --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 18, 2013 at 08:13:08AM -0400, Peter Todd wrote: > A more sophisticated approach would be possible if there existed a > version of H() with a computational trap-door - that is if there existed > H'(s, i)=3DH(i) where H' had significantly faster running time than H(), > but required knowledge of a secret. Our peers would then be able to > answer our challenges quickly only if they stored the intermediate > results in a lookup table, while we could check those challenges cheaply > without that table. >=20 > Adam: you're our local crypto-expert, what can we use for H'? Seems that > maybe some kind of asymmetric crypto system would work by requiring the > peer to crack weak secret keys that we generate deterministicly. Actually, come to think of it a really easy way to create H' is for the node to create some expensive to compute set of data associated with their identity. The data set is then stored once by the node, cheap, but the clients have to store one set for every unique node they connect too, expensive. A set of the function scrypt(k | i) for i in 0..n is an obvious way to do it. This can equally be used as a proof-of-work to make creating lots of nodes expensive given a cheap way to verify the POW; easily done with a non-interactive zero-knowledge proofs. It'd be nice if that POW could incorporate blockchain data, showing that the identity had access to that data and thus could have computed the UTXO set honestly. (the POW should be incrementally extendable as new data becomes available) However that is back to using a bunch of bandwidth at startup if our peer doesn't have access to blockchain data, so both mechanisms would probably have to be done independently. Note how we also make MITM attacks on encrypted P2P connections expensive this way too even without any form of authentication. (works best when the proof-of-work is dependent on your IP addresses) --=20 'peter'[:-1]@petertodd.org 00000000000000762784b647ede3678f172d73dd0c72c2180ab451b00d756959 --fUYQa+Pmc3FrFX/N Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlHn6ywACgkQpEFN739thoyPPACdE1HtBjHJo7dVG/mpJeCaUlQ9 3H0AniXXYrL0dNBjmdQGLD0urlkDopeg =njm7 -----END PGP SIGNATURE----- --fUYQa+Pmc3FrFX/N--