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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jeremy@taplink.co>) id 1W2dfQ-00017O-5O
for bitcoin-development@lists.sourceforge.net;
Mon, 13 Jan 2014 09:18:44 +0000
Received-SPF: pass (sog-mx-1.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-1.v43.ch3.sourceforge.com with smtp (Exim 4.76)
id 1W2dfP-0002Bx-7R for bitcoin-development@lists.sourceforge.net;
Mon, 13 Jan 2014 09:18:44 +0000
Received: from laptop-air.hsd1.ca.comcast.net ([192.168.168.135]) by
mail.taplink.co ; Mon, 13 Jan 2014 01:27:04 -0800
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
Date: Mon, 13 Jan 2014 01:18:39 -0800
To: "bitcoin-development@lists.sourceforge.net"
<bitcoin-development@lists.sourceforge.net>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: "Jeremy Spilman" <jeremy@taplink.co>
Organization: TapLink
Message-ID: <op.w9mb5dv0yldrnw@laptop-air.hsd1.ca.comcast.net>
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: 1W2dfP-0002Bx-7R
Subject: [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 09:18:44 -0000
* Transaction *
I spent 1BTC on TestNet to a stealth address...
TxID: df092896c1347b303da299bc84c92bef1946f455dbdc80ffdb01a18ea4ed8b4c
http://blockexplorer.com/testnet/tx/df092896c1347b303da299bc84c92bef1946f455dbdc80ffdb01a18ea4ed8b4c#i8166574
* Code *
Code which generated this transaction is here:
https://gist.github.com/jspilman/8396495
Note, one minor change from the protocol we discussed is I'm just using
the 32-byte x coordinate for the shared secret, not the compressed pubKey
(so, throwing away the first byte) before hashing with SHA256.
* How it Looks *
After importing the privkey for the TxIn to that transaction
(importprivkey "cNL8XqRtqwC1YEc9kKspbX2aukWnXfgHQSvjsPYbuPif5Q3DJkEs"
rescan) you will see two rows in the Transaction List of Bitcoin-QT...
Both rows simply say 'Sent to' with a blank address. One has 1BTC amount
which is the 2-of-2 stealth multisig, the other has 0BTC amount, and it's
the OP_RETURN.
I wonder if the 0BTC OP_RETURN transactions should be hidden from the
Transaction List? 'Transaction Details' truncates the <data> after
OP_RETURN anyway, so it's not even particularly useful for seeing what
data you embedded.
* Next Steps *
I'm not quite sure. If we're going to try to deploy this, I think we need
to fully understand what users who are making these payments should see in
their wallet software while making a payment, and after a payment has been
made.
Right now I'm thinking...
1) Define the PaymentRequest extension
2) Update Gavin's PHP to generate PaymentRequests for stealth payments
3) Get Bitcoin-QT loading the PaymentRequest and generating transactions
from those PaymentRequests
4) Write an agent to detect incoming stealth payments
But we would still be showing meaningless rows in the payer's Transaction
List without some additional work.
If there is a place to add TxOut meta-data with the pubkeys used to
generate it... well, there must be since the 'Merchant' field is attached
somehow. So we could probably use the same method to keep the pubKeys
around.
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. We could skip
saving the pubKeys for now, so there would be no way to send follow on
stealth payments, but at least the Transaction List would make sense
instead of looking like two empty transactions.
* Other Open Questions *
I think the biggest is if/how to receive P2P stealth payments in
Bitcoin-QT as an end-user not a merchant.
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?
And then there's still the question of: when 'd1'/Q1 is available
decrypted, we must fully verify the transaction, and how to indicate if
that has or has not been done yet.
It really seems crippled to me without fully integrated support for
receiving P2P stealth payments in Bitcoin-QT. It doesn't seem like that
much code, just some details to work out first.
|
