From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <jeremy@taplink.co>) id 1W39Pp-0005Az-RY
	for bitcoin-development@lists.sourceforge.net;
	Tue, 14 Jan 2014 19:12:45 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of taplink.co
	designates 50.117.27.232 as permitted sender)
	client-ip=50.117.27.232; envelope-from=jeremy@taplink.co;
	helo=mail.taplink.co; 
Received: from mail.taplink.co ([50.117.27.232])
	by sog-mx-4.v43.ch3.sourceforge.com with smtp (Exim 4.76)
	id 1W39Pp-00040x-2U for bitcoin-development@lists.sourceforge.net;
	Tue, 14 Jan 2014 19:12:45 +0000
Received: from laptop-air.hsd1.ca.comcast.net ([192.168.168.135]) by
	mail.taplink.co ; Tue, 14 Jan 2014 11:22:03 -0800
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
To: "Peter Todd" <pete@petertodd.org>
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>
	<20140114141908.GB29950@savin>
Date: Tue, 14 Jan 2014 11:12:40 -0800
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: "Jeremy Spilman" <jeremy@taplink.co>
Organization: TapLink
Message-ID: <op.w9oybextyldrnw@laptop-air.hsd1.ca.comcast.net>
In-Reply-To: <20140114141908.GB29950@savin>
User-Agent: Opera Mail/1.0 (Win32)
oclient: 192.168.168.135#jeremy@taplink.co#465
X-Spam-Score: -1.7 (-)
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
	-0.1 RP_MATCHES_RCVD Envelope sender domain matches handover relay
	domain
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1W39Pp-00040x-2U
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Stealth Addresses
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Tue, 14 Jan 2014 19:12:46 -0000

On Tue, 14 Jan 2014 06:19:08 -0800, Peter Todd <pete@petertodd.org> wrote:

> On Mon, Jan 13, 2014 at 02:02:00PM -0800, Jeremy Spilman wrote:
>> I decided to put both pubKeys in a 2-of-2 multisig, instead of keeping  
>> one of the pubKeys in the OP-RETURN, to prevent a malicious sender from  
>> triggering false positives on your online detection key when the funds  
>> are actually still fully controlled by the payer.
>>
>> 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.
>
> 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.
>

Right now I have this:

   byte[] e = EC.NewPrivateKey();
   byte[] P = EC.GetPublicKey(e, compressed: true);
   byte[] S1 = EC.DH(e, Q1);
   byte[] S2 = EC.DH(e, Q2);
   byte[] q1New = EC.PointAdd(Q1, Util.SingleSHA256(S1));
   byte[] q2New = EC.PointAdd(Q2, Util.SingleSHA256(S2));
   stealthTx.Vout.Add(TxOut.PayToMultiSig(Util.Amount(".995"), 2, 2, q1New,  
q2New));
   stealthTx.Vout.Add(TxOut.OpReturn(P));

In this case, you can scan with d2, calculate S2, and matching payments  
will have the right 'q2New'. But you need to check again offline with d1  
since it's a separate shared secret.

Maybe you are saying:

   byte[] S = EC.DH(e, Q2);
   byte[] q1New = EC.PointAdd(Q1, Util.SingleSHA256(S));
   byte[] q2New = EC.PointAdd(Q2, Util.SingleSHA256(S));

But the payment would have (q2New - q1New) == (Q2 - Q1), so I think not  
entirely stealth? OK, let's fix that by adding a counter to the hash  
function...

   byte[] S = EC.DH(e, Q2);
   byte[] q1New = EC.PointAdd(Q1, Util.SingleSHA256(S || 1));
   byte[] q2New = EC.PointAdd(Q2, Util.SingleSHA256(S || 2));
   stealthTx.Vout.Add(TxOut.PayToMultiSig(Util.Amount(".995"), 2, 2, q1New,  
q2New));
   stealthTx.Vout.Add(TxOut.OpReturn(P));

This is assuming we want to put q2New somewhere into the transaction,  
which, is it even required?

   byte[] S = EC.DH(e, Q2);
   byte[] q1New = EC.PointAdd(Q1, Util.SingleSHA256(S));
   stealthTx.Vout.Add(TxOut.PayToPubKeyHash(Util.Amount(".995"), q1New);
   stealthTx.Vout.Add(TxOut.OpReturn(P));

I'll wait for ACK and then update my sample code.