Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.148.110 as permitted sender)
	client-ip=62.13.148.110; envelope-from=pete@petertodd.org;
	helo=outmail148110.authsmtp.com; 
Date: Tue, 14 Jan 2014 09:19:08 -0500
From: Peter Todd <pete@petertodd.org>
To: Jeremy Spilman <jeremy@taplink.co>
Message-ID: <20140114141908.GB29950@savin>
References: <op.w9c5o7vgyldrnw@laptop-air.hsd1.ca.comcast.net>
	<20140110102037.GB25749@savin>
	<op.w9kkxcityldrnw@laptop-air.hsd1.ca.comcast.net>
	<CABsx9T2G=yqSUGr0+Ju5-z9P++uS20AwLC+c3DnFMHtcQjQK6w@mail.gmail.com>
	<CAAS2fgTz0TaGhym_35V3N2-vHVzU9BeuV8q+QJjwh5bg77FEZg@mail.gmail.com>
	<20140113194049.GJ38964@giles.gnomon.org.uk>
	<CANAnSg30V01B_3LCJ09sTwcsYa4_WOg3sKd-=p6COZS6w0b-uA@mail.gmail.com>
	<52D4458C.6010909@gmail.com>
	<CAAS2fgTzVWUF_B_-1jkRs3WZ8Um_CcHeH7uFU0eLncgEqQ01HQ@mail.gmail.com>
	<19AE1549-16E0-4119-8BE9-8F4DFD3381C1@taplink.co>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="oC1+HKm2/end4ao3"
Content-Disposition: inline
In-Reply-To: <19AE1549-16E0-4119-8BE9-8F4DFD3381C1@taplink.co>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Stealth Addresses
Precedence: list


--oC1+HKm2/end4ao3
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Jan 13, 2014 at 02:02:00PM -0800, Jeremy Spilman wrote:
>=20
> > Uh while I'm responding again, what I'd discussed with Peter Todd in
> > IRC used two EC points in the stealth address. One for the payment and
> > one for the ECDH.  The reason to use two is that it makes delegating
> > detection possible and so you don't have to have you spending keys
> > online to even detect these payments.  Why'd that get dropped?
>=20
> I think this is exactly what I've implemented.
>=20
> I decided to put both pubKeys in a 2-of-2 multisig, instead of keeping on=
e of the pubKeys in the OP-RETURN, to prevent a malicious sender from trigg=
ering false positives on your online detection key when the funds are actua=
lly still fully controlled by the payer.
>=20
> You can still have a false positive (only 1 of 2 keys actually yours) but=
 the funds would be trapped so it's unlikely anyone would do it.=20

How would they trigger false positives? The payee recovers the nonce
with ECDH from the payor's ephemereal pubkey and their online detection
secret key. They use BIP32 public derivation with their offline spending
pubkey(s), if the derived pubkeys match the actual scriptPubKey they
know the output is spendable by them. I don't see how that can go wrong.

--=20
'peter'[:-1]@petertodd.org
000000007dd7a87aec311fb7fb13770f54edf628e6976f8c6091a5b2638878a7

--oC1+HKm2/end4ao3
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQGrBAEBCACVBQJS1UdbXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwN2RkN2E4N2FlYzMxMWZiN2ZiMTM3NzBmNTRlZGY2MjhlNjk3NmY4YzYw
OTFhNWIyNjM4ODc4YTcvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfsV8Qf+LQ5Gdb3uKMh95chR1IonmIzK
0n3P8E59oYpc/b7YLANfHAUARh/SYkDV/f5Sq5q38bvcGY61suOVqL6FPI2fMYEj
N96hhNWPlqgqj9m4ak2vVnaX193ImVa5tsaDjBPOXCztr7DVoNqy0v+a/TFl3Eu6
Fqr4pm8y9M1fmjOlen+DBEnSTNJgs1hJcCeZy1Qe7+eDTCaqYf4nHmU7Zl2xkFXn
vHf40N2L5HyTJilWgPHD2KnSVNERGp7F7c4hGvW2YzAUi+YLPypvPH/T19o9Ldgv
pZuprzTBA3c3TCTHjzOXwBcK8TNGai+7BTH1USQDUqfbl1lzJKv1C0dbxWagPQ==
=l02T
-----END PGP SIGNATURE-----

--oC1+HKm2/end4ao3--