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 1UZQ1D-000360-Co for bitcoin-development@lists.sourceforge.net; Mon, 06 May 2013 18:20:12 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.148.98 as permitted sender) client-ip=62.13.148.98; envelope-from=pete@petertodd.org; helo=outmail148098.authsmtp.com; Received: from outmail148098.authsmtp.com ([62.13.148.98]) by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1UZQ1C-0002du-7R for bitcoin-development@lists.sourceforge.net; Mon, 06 May 2013 18:20:11 +0000 Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt12.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id r46IK3NT061623; Mon, 6 May 2013 19:20:03 +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 r46IK0uK006751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 6 May 2013 19:20:02 +0100 (BST) Date: Mon, 6 May 2013 14:19:59 -0400 From: Peter Todd To: Gregory Maxwell Message-ID: <20130506181959.GC22505@petertodd.org> References: <20130506161216.GA5193@petertodd.org> <20130506163732.GB5193@petertodd.org> <20130506171943.GA22505@petertodd.org> <20130506175331.GB22505@petertodd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+xNpyl7Qekk2NvDX" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 91cc2c49-b679-11e2-b5c5-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdgQUFVQNAgsB AmUbWl1eUl17WWE7 ag1VcwRfa1RMVxto VEFWR1pVCwQmQxgH f2UeF2JydwNBfX8+ Z0ZjWngVVUUpJkQu RkdJR2sBbHphaTUd TRJdJAZJcANIexZF O1F6ACIKLwdSbGoL NQ4vNDcwO3BTJTpY RgYVKF8UXXNDMj8n TBccEC8+WkQJSz97 NxUtKVMABw5RLUwp YxMaVEgGMhQfQgdf A1ovSCFePREZXTct AA8SW0kSHSYcKQAA X-Authentic-SMTP: 61633532353630.1023: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: 1UZQ1C-0002du-7R 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 18:20:12 -0000 --+xNpyl7Qekk2NvDX Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 06, 2013 at 11:01:22AM -0700, Gregory Maxwell wrote: > On Mon, May 6, 2013 at 10:53 AM, Peter Todd wrote: > > We don't have non-repudiation now, why make that a requirement for the > > first version? Adding non-repudiation is something that has to happen at > > the Bitcoin protocol level,(1) so it's orthogonal to using SSL to make = sure > > you're connection isn't being tampered with and is encrypted. >=20 > Because if you just want bitcoin p2p over SSL... just start up stunnel > on another port. Done. You've still solved nothing about the problem > of discovery issue. stunnel only works if both sides support it. re: discovery, the whole reason I brought up SSL was the idea that a seed whome you have a secure connection to, like HTTPS or SSL, can include the peer pubkey along with the peer's IP address, allowing you to be sure you've connected to the peer the seed is giving you rather than some other imposter. Equally it'll let you be sure you've connected to the correct peer the second time. For applications where you *don't* need non-repudiation SSL is already implemented and solves the secure peer communication issue, including encryption, in an efficient way without requiring a lot of code complexity to implement. SSL could be implemented as a Google Summar of Code project by an average developer, and importantly re-implemented by all the alt-clients out there with relatively little work. It may even be the case that some usage scenarios do find the CA system useful. I might want to do -addnode ssl://petertodd.org on my Android wallet to be sure I've connected to my Bitcoin node rather than some MITM ISP imposter. I already have a SSL cert from a CA for petertodd.org that I can use and my Android phone already has a list of CA's I can put a reasonable amount of trust in. > > 1) Non-repudiation is only useful with fraud proofs, and they will have > > to be thought out for everything the node might claim. >=20 > That isn't so. If a node is reliably rogue I can go manually gather > evidence and people can manually take action against it. Consider the > DNSseeds, right now fraud proofs really wouldn't matter=E2=80=94 the limi= ted > amount of trust put in those things is based not on "oh no, nodes will > ignore you in the future if you're bad", it's based on the ability of > misconduct to sully the operator's reputation. Sure, but how will non-repudiation be implemented? By having the node sign the messages they send with their pubkey, and as Mike suggests likely doing so in some sort of chained hash or preferably merkle mountain range to allow for constructing proofs over multiple messages. That has nothing to do with encrypting the transport, and will always be a lot slower than SSL's symmetric cipher for when you don't need non-repudiation but do want to be sure you've connected to the right node. > > Anyway, the concept of a per-node identity keypair is the first step > > towards non-repudiation, and implementing SSL transport. >=20 > Yea, indeed, per-node keys are useful for a bunch of things. Care is > needed to avoid problems like deanonymizing use over tor with them. Per-node keys really need to be per listening address by default. In fact, I'd argue for creating new keys on startup by default. --=20 'peter'[:-1]@petertodd.org 000000000000015ef6fc2fc45adc1de0c344e99a59453bb09ac470a1d02b787d --+xNpyl7Qekk2NvDX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlGH9E8ACgkQpEFN739thoz/qQCdHSpb9whlOM9SuVXhYx6nTI3p YbwAn2dNCwaNTmz2dfbRQZiDu7JFhDNb =GhcJ -----END PGP SIGNATURE----- --+xNpyl7Qekk2NvDX--