Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WimL0-0003Go-Cx for bitcoin-development@lists.sourceforge.net; Fri, 09 May 2014 15:03:50 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.148.112 as permitted sender) client-ip=62.13.148.112; envelope-from=pete@petertodd.org; helo=outmail148112.authsmtp.co.uk; Received: from outmail148112.authsmtp.co.uk ([62.13.148.112]) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1WimKy-0004Ce-Sm for bitcoin-development@lists.sourceforge.net; Fri, 09 May 2014 15:03:50 +0000 Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt17.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s49F3gZV037721; Fri, 9 May 2014 16:03:42 +0100 (BST) Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s49F3cKP036029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 9 May 2014 16:03:40 +0100 (BST) Date: Fri, 9 May 2014 11:03:25 -0400 From: Peter Todd To: Mike Hearn Message-ID: <20140509150325.GA30436@savin> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="liOOAslEiF7prFVr" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 1b57d233-d78b-11e3-b396-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdgsUFVQNAgsB AmIbWlJeUF57XWI7 bAxPbAVDY01GQQRq WVdMSlVNFUsrBRV3 BU1lMhlxcQVEcTBx ZU9jWj5aDkF9IUR+ QVMAEmVUeGZhPWMC AkNRcR5UcAFPdx8U a1UrBXRDAzANdhES HhM4ODE3eDlSNilR RRkIIFQOdA4mNRIc DxEEVSkvEAUdTjQ2 Iho6YkYGG1oWOUI2 Wc+0 X-Authentic-SMTP: 61633532353630.1023:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 76.10.178.109/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: 1WimKy-0004Ce-Sm Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] ECDH in the payment protocol 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: Fri, 09 May 2014 15:03:50 -0000 --liOOAslEiF7prFVr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 09, 2014 at 02:05:24PM +0200, Mike Hearn wrote: It's always interesting to see the reinvention cycle happen in the Bitcoin space as ideas get proposed over and over again; I'm sure Amir Taaki will be pleased to read this as it is a slightly less sophisticated version of what he originally proposed to me for the design of what became stealth addresses. Of course we quickly rejected the idea of depending solely on a communications backchannel to retrieve funds. Any communications medium that isn't the blockchain makes the payment non-atomic, and thus creates opportunities for it to fail. Fortunately we already have the necessary ephemeral keys in standard Bitcoin transactions in pay-to-pubkey-hash and pay-to-script-hash spending scriptSigs so you don't need to compromise on reliability in exchange for transaction size as you're mistakingly assuming. You should re-read my original stealth address discussion with Gregory Maxwell on IRC if this is unclear. In any case it's a mistake to argue that some times of data in the blockchain are "bloat" by virtue of whether or not they happen to be executed in a script. Multisig addresses use an extra ~107 bytes of data per signature per txout spend to make it less likely for the user to lose their funds under certain conditions; op-return-using stealth addresses use an extra ~50 bytes of data per txout spend to make the user less likely to lose their funds and make their transactions more private under certain conditions.(1) Ultimately the resource being used is the same, making it silly to try to dictate the right trade-offs by brushing certain solutions as anti-social "bloat" and others not based on top-down edict; let the free market for fees do its job. 1) Note that the recent advancements in ECDH multi-party signing are limited in the cases they can cover; there still is a strong need for discrete key multisig, e.g. for Greenaddress.it --=20 'peter'[:-1]@petertodd.org 00000000000000003581a7e5d0e10205803803466240668215d178b216837386 --liOOAslEiF7prFVr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQGrBAEBCACVBQJTbO45XhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAxNWVkOTEzZmZmMGNlOTFkY2E4NGI1ZTcyZTQ1OTZlZWQ1 MTM2NmZlOTk5YTE4YzYvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfv+3wgApwVopbVrrBc6I0mJWC4IXMDw y2p6fPGIJH1bYxFxKefVkiWIHngDyczGug98+6u+L+30AYGKcdVKDDYsE1ISrm+P gbAjry0+7crrZSipCbul7q0+MtoZ8VPIcH9e0GbCJ+IIgbjwJzQ+VEAP8135rujx wP/mQw5mPsalKIouMn3C3Qt5g2iFT705JIs7/8OT5di8kBrpZcG6byqbr/y5FiOs L8Hihg9DnLBRHwXkwu+SCyLqF0mKWTU+5kYN2G6/CU8PxHc6dhQwYcGmqVPVgkYV E6COfJ50Flz5B4fvS33HBuLk6RrL4x8D1SrzCmq1X61/dxU6rmDSRRpf+A4vfQ== =Yu7w -----END PGP SIGNATURE----- --liOOAslEiF7prFVr--