1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
|
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.
|
