summaryrefslogtreecommitdiff
path: root/4c/2412711f14fb4eaafccccaa424499293c68224
blob: 6bca2dbc90f9b8841d244ca1a91db65eccf1061b (plain)
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
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
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 <mh.in.england@gmail.com>) id 1W2fXO-0004QD-Hm
	for bitcoin-development@lists.sourceforge.net;
	Mon, 13 Jan 2014 11:18:34 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.214.172 as permitted sender)
	client-ip=209.85.214.172; envelope-from=mh.in.england@gmail.com;
	helo=mail-ob0-f172.google.com; 
Received: from mail-ob0-f172.google.com ([209.85.214.172])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1W2fXN-0000Hl-GG
	for bitcoin-development@lists.sourceforge.net;
	Mon, 13 Jan 2014 11:18:34 +0000
Received: by mail-ob0-f172.google.com with SMTP id gq1so7587119obb.31
	for <bitcoin-development@lists.sourceforge.net>;
	Mon, 13 Jan 2014 03:18:28 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.182.87.42 with SMTP id u10mr20051075obz.22.1389611908086;
	Mon, 13 Jan 2014 03:18:28 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.76.99.112 with HTTP; Mon, 13 Jan 2014 03:18:28 -0800 (PST)
In-Reply-To: <op.w9mb5dv0yldrnw@laptop-air.hsd1.ca.comcast.net>
References: <op.w9mb5dv0yldrnw@laptop-air.hsd1.ca.comcast.net>
Date: Mon, 13 Jan 2014 12:18:28 +0100
X-Google-Sender-Auth: CPtLVC7NLzrmIXYhrPzPYKFXeE0
Message-ID: <CANEZrP38DsYP4KRk1Jz_hiMrP_ZPCj6=TDKmr-t-r2BJRMjDSQ@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Jeremy Spilman <jeremy@taplink.co>
Content-Type: multipart/alternative; boundary=089e013cba6228434c04efd83c53
X-Spam-Score: -0.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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(mh.in.england[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	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: 1W2fXN-0000Hl-GG
Cc: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Stealth Payments - Sample Code / Proof of
	Concept
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: Mon, 13 Jan 2014 11:18:34 -0000

--089e013cba6228434c04efd83c53
Content-Type: text/plain; charset=UTF-8

Cool!

On Mon, Jan 13, 2014 at 10:18 AM, Jeremy Spilman <jeremy@taplink.co> wrote:

> I spent 1BTC on TestNet to a stealth address...
>     TxID: df092896c1347b303da299bc84c92bef1946f455dbdc80ffdb01a18ea4ed8b4c
>

... but can you redeem it?


> Code which generated this transaction is here:
> https://gist.github.com/jspilman/8396495


That's rather interesting code. Is this using a private C# bitcoin
implementation?


> I wonder if the 0BTC OP_RETURN transactions should be hidden from the
> Transaction List?
>

Yes, of course. The transaction list should just say something like

    "Payment received from Jeremy,  0.1 BTC"

Maybe the simple way to punt on this is to just show 'Merchant' in the
> address column if it is available and an address is not.


I am surprised it's not already the case! Though "merchant" is perhaps a
bit biased as a name, internally it perhaps should just be called
"Recipient". There's no requirement for you to be a merchant to create
payment protocol requests.


> I can probably make the necessary changes to IsMine, but I don't know
> where we should keep 'd2'/'Q2' unencrypted so it's available for doing the
> necessary tests, but has no chance of ever be used as a stand-alone
> private key?
>

The wallet format would need extending.

I'd feel a lot more comfortable if the protocol was reviewed by a
professional cryptographer though. I think think Gregory already brought up
an issue to do with people able to detect such payments by testing if
decrypted values are points on the curve, or something like that.

--089e013cba6228434c04efd83c53
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Cool!<div><br></div><div class=3D"gmail_extra"><div class=
=3D"gmail_quote">On Mon, Jan 13, 2014 at 10:18 AM, Jeremy Spilman <span dir=
=3D"ltr">&lt;<a href=3D"mailto:jeremy@taplink.co" target=3D"_blank">jeremy@=
taplink.co</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">I spent 1BTC on TestNet to a stealth address=
...<br>
=C2=A0 =C2=A0 TxID: df092896c1347b303da299bc84c92bef1946f455dbdc80ffdb01a18=
ea4ed8b4c<br></blockquote><div><br></div><div>... but can you redeem it?</d=
iv><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Code which generated this transaction is here:<br>
<a href=3D"https://gist.github.com/jspilman/8396495" target=3D"_blank">http=
s://gist.github.com/jspilman/8396495</a></blockquote><div><br></div><div>Th=
at&#39;s rather interesting code. Is this using a private C# bitcoin implem=
entation?</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">I wonder if the 0BTC OP_RET=
URN transactions should be hidden from the<br>
Transaction List?<br></blockquote><div><br></div><div>Yes, of course. The t=
ransaction list should just say something like</div><div><br></div><div>=C2=
=A0 =C2=A0 &quot;Payment received from Jeremy, =C2=A00.1 BTC&quot;</div><di=
v><br></div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Maybe the simple way to punt on this is to j=
ust show &#39;Merchant&#39; in the<br>
address column if it is available and an address is not.</blockquote><div><=
br></div><div>I am surprised it&#39;s not already the case! Though &quot;me=
rchant&quot; is perhaps a bit biased as a name, internally it perhaps shoul=
d just be called &quot;Recipient&quot;. There&#39;s no requirement for you =
to be a merchant to create payment protocol requests.</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">I can probably make the nec=
essary changes to IsMine, but I don&#39;t know<br>
where we should keep &#39;d2&#39;/&#39;Q2&#39; unencrypted so it&#39;s avai=
lable for doing the<br>
necessary tests, but has no chance of ever be used as a stand-alone<br>
private key?<br></blockquote><div><br></div><div>The wallet format would ne=
ed extending.</div><div><br></div><div>I&#39;d feel a lot more comfortable =
if the protocol was reviewed by a professional cryptographer though. I thin=
k think Gregory already brought up an issue to do with people able to detec=
t such payments by testing if decrypted values are points on the curve, or =
something like that.</div>
</div></div></div>

--089e013cba6228434c04efd83c53--