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; 
Date: Fri, 9 May 2014 11:03:25 -0400
From: Peter Todd <pete@petertodd.org>
To: Mike Hearn <mike@plan99.net>
Message-ID: <20140509150325.GA30436@savin>
References: <CANEZrP3VNXSc2cd3b9pz9iC2BR0-vG=tfYwMyUGBGaWPq+geXQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="liOOAslEiF7prFVr"
Content-Disposition: inline
In-Reply-To: <CANEZrP3VNXSc2cd3b9pz9iC2BR0-vG=tfYwMyUGBGaWPq+geXQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] ECDH in the payment protocol
Precedence: list


--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--