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
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
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 1WijYR-0003OJ-9E
for bitcoin-development@lists.sourceforge.net;
Fri, 09 May 2014 12:05:31 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.42 as permitted sender)
client-ip=209.85.219.42; envelope-from=mh.in.england@gmail.com;
helo=mail-oa0-f42.google.com;
Received: from mail-oa0-f42.google.com ([209.85.219.42])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WijYP-0000DO-SB
for bitcoin-development@lists.sourceforge.net;
Fri, 09 May 2014 12:05:31 +0000
Received: by mail-oa0-f42.google.com with SMTP id j17so4798218oag.29
for <bitcoin-development@lists.sourceforge.net>;
Fri, 09 May 2014 05:05:24 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.132.236 with SMTP id ox12mr2967658oeb.81.1399637124290;
Fri, 09 May 2014 05:05:24 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.71.162 with HTTP; Fri, 9 May 2014 05:05:24 -0700 (PDT)
Date: Fri, 9 May 2014 14:05:24 +0200
X-Google-Sender-Auth: hvabxCCXKsyc9emIXFgsWYShCAE
Message-ID: <CANEZrP3VNXSc2cd3b9pz9iC2BR0-vG=tfYwMyUGBGaWPq+geXQ@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=047d7b41cd289b9ec804f8f669dc
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: 1WijYP-0000DO-SB
Subject: [Bitcoin-development] ECDH in the payment protocol
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: Fri, 09 May 2014 12:05:31 -0000
--047d7b41cd289b9ec804f8f669dc
Content-Type: text/plain; charset=UTF-8
I wrote an article about an ECDH extension for BIP 70:
https://medium.com/p/cb2f81962c1b
The article is meant for people who don't follow bitcoin-development so
I'll summarise it here:
- The notion of being able to publish a piece of data once and use it to
receive lots of payments without any coordination is really useful. This is
the idea behind the stealth address proposal.
- Stealth addresses don't fit with the payment protocol, because they're
a new kind of address (obviously).
- Stealth addresses are not backwards compatible. If you give someone a
stealth address and their wallet doesn't support it, they can't pay you,
not even with worse privacy. Sometimes people may optionally want that
behaviour but stealth addresses have it all the time.
- The proposed stealth address design makes huge sacrifices to try and
keep everything within the block chain. It bloats the chain with OP_RETURN
stuff that isn't a part of the validation. But more seriously, the only way
to make it efficient enough for lightweight clients is to reduce the
"stealthyness". The more efficient you make your address the less private
it becomes. This is somewhat similar to the dilemma we have with Bloom
filtering, except Bloom filters are transient and can only be used to link
addresses by someone who observes them on the wire. Stealth addresses
record the relationship in the block chain forever.
- The design makes these sacrifices to avoid moving data around outside
the block chain. But with BIP 70 that's the direction we're heading in
anyway. So by adding ECDH to the payment protocol and putting our effort
into making BIP 70 work really well for everyone, we end up killing
multiple birds with one stone. The same work that resolves the privacy
problems inherent in the stealth address design also allows us to attach
messages to payments and other commonly requested features.
There's a straw man in the article that I recreate here:
message Output {
optional uint64 amount = 1 [default = 0];
optional bytes script = 2;
*optional boolean accept_ecdh = 3; // Requires script to be a
pay-to-pubkey output.*
}
message Payment {
optional bytes merchant_data = 1;
repeated bytes transactions = 2;
repeated Output refund_to = 3;
optional string memo = 4;
*repeated bytes ecdh_nonces = 5;*
}
The way the nonces are combined to arrive at the address could be the same
as in the current stealth address spec. A wallet that doesn't understand
ECDH but does understand raw BIP 70 would deliver the money to the base
address, which receiving wallets would look for too - so it's backwards
compatible. The nonces stay out of the block chain. The transactions are
delivered directly to the recipient so there's no problems with trying to
make it fit with Bloom/prefix filtering.
To make this work there obviously has to be a backchannel from payer to
payee. BIP 70 is mostly used by web shops today so that back channel is
just HTTPS to the website itself, but shops benefit less from ECDH than
others do. So we need a simple email-like store and forward network where
HTTP POSTs to a server get queued up and delivered later (or possibly
forwarded to another store-and-forward network like the Android push
network). Most of the article discusses how best to build such a thing.
The justification for the original stealth address design can be summed up
as "it's easier to [ab]use the Bitcoin network for delivery of short
messages than use a different system". But there are just so many features
we may want to add into the Payment message in future it seems better to
crack the SaF problem earlier rather than continue trying to jam a square
peg into a round hole. There are lots of very reliable SAF networks around
(email, instant messaging, etc) so it doesn't seem infeasible.
Thoughts welcome!
--047d7b41cd289b9ec804f8f669dc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I wrote an article about an ECDH extension for BIP 70:<div=
><br></div><div>=C2=A0 =C2=A0<a href=3D"https://medium.com/p/cb2f81962c1b">=
https://medium.com/p/cb2f81962c1b</a><br></div><div><br></div><div>The arti=
cle is meant for people who don't follow bitcoin-development so I'l=
l summarise it here:</div>
<div><ul><li>The notion of being able to publish a piece of data once and u=
se it to receive lots of payments without any coordination is really useful=
. This is the idea behind the stealth address proposal.<br><br></li><li>
Stealth addresses don't fit with the payment protocol, because they'=
;re a new kind of address (obviously).<br><br></li><li>Stealth addresses ar=
e not backwards compatible. If you give someone a stealth address and their=
wallet doesn't support it, they can't pay you, not even with worse=
privacy. Sometimes people may optionally want that behaviour but stealth a=
ddresses have it all the time.<br>
<br></li><li>The proposed stealth address design makes huge sacrifices to t=
ry and keep everything within the block chain. It bloats the chain with OP_=
RETURN stuff that isn't a part of the validation. But more seriously, t=
he only way to make it efficient enough for lightweight clients is to reduc=
e the "stealthyness". The more efficient you make your address th=
e less private it becomes. This is somewhat similar to the dilemma we have =
with Bloom filtering, except Bloom filters are transient and can only be us=
ed to link addresses by someone who observes them on the wire. Stealth addr=
esses record the relationship in the block chain forever.<br>
<br></li><li>The design makes these sacrifices to avoid moving data around =
outside the block chain. But with BIP 70 that's the direction we're=
heading in anyway. So by adding ECDH to the payment protocol and putting o=
ur effort into making BIP 70 work really well for everyone, we end up killi=
ng multiple birds with one stone. The same work that resolves the privacy p=
roblems inherent in the stealth address design also allows us to attach mes=
sages to payments and other commonly requested features.</li>
</ul><div>There's a straw man in the article that I recreate here:</div=
></div><div><br></div><div><div><font face=3D"courier new, monospace">messa=
ge Output {</font></div><div><font face=3D"courier new, monospace">=C2=A0 =
=C2=A0optional uint64 amount =3D 1 [default =3D 0];</font></div>
<div><font face=3D"courier new, monospace">=C2=A0 =C2=A0optional bytes scri=
pt =3D 2;=C2=A0</font></div><div><font face=3D"courier new, monospace">=C2=
=A0 =C2=A0<b>optional boolean accept_ecdh =3D 3; =C2=A0// Requires script t=
o be a pay-to-pubkey output.</b></font></div>
<div><font face=3D"courier new, monospace">}</font></div></div><div><font f=
ace=3D"courier new, monospace"><br></font></div><div><div><font face=3D"cou=
rier new, monospace">message Payment {</font></div><div><font face=3D"couri=
er new, monospace">=C2=A0 =C2=A0optional bytes merchant_data =3D 1;</font><=
/div>
<div><font face=3D"courier new, monospace">=C2=A0 =C2=A0repeated bytes tran=
sactions =3D 2;</font></div><div><font face=3D"courier new, monospace">=C2=
=A0 =C2=A0repeated Output refund_to =3D 3;</font></div><div><font face=3D"c=
ourier new, monospace">=C2=A0 =C2=A0optional string memo =3D 4;=C2=A0</font=
></div>
<div><font face=3D"courier new, monospace">=C2=A0 =C2=A0<b>repeated bytes e=
cdh_nonces =3D 5;</b>=C2=A0</font></div><div><font face=3D"courier new, mon=
ospace">}</font></div></div><div><br></div><div>The way the nonces are comb=
ined to arrive at the address could be the same as in the current stealth a=
ddress spec. A wallet that doesn't understand ECDH but does understand =
raw BIP 70 would deliver the money to the base address, which receiving wal=
lets would look for too - so it's backwards compatible. The nonces stay=
out of the block chain. The transactions are delivered directly to the rec=
ipient so there's no problems with trying to make it fit with Bloom/pre=
fix filtering.</div>
<div><br></div><div>To make this work there obviously has to be a backchann=
el from payer to payee. BIP 70 is mostly used by web shops today so that ba=
ck channel is just HTTPS to the website itself, but shops benefit less from=
ECDH than others do. So we need a simple email-like store and forward netw=
ork where HTTP POSTs to a server get queued up and delivered later (or poss=
ibly forwarded to another store-and-forward network like the Android push n=
etwork). Most of the article discusses how best to build such a thing.</div=
>
<div><br></div><div>The justification for the original stealth address desi=
gn can be summed up as "it's easier to [ab]use the Bitcoin network=
for delivery of short messages than use a different system". But ther=
e are just so many features we may want to add into the Payment message in =
future it seems better to crack the SaF problem earlier rather than continu=
e trying to jam a square peg into a round hole. There are lots of very reli=
able SAF networks around (email, instant messaging, etc) so it doesn't =
seem infeasible.</div>
<div><br></div><div>Thoughts welcome!</div></div>
--047d7b41cd289b9ec804f8f669dc--
|
