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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <prabahy@gmail.com>) id 1VrA4K-00051O-7A
for bitcoin-development@lists.sourceforge.net;
Thu, 12 Dec 2013 17:29:00 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.175 as permitted sender)
client-ip=74.125.82.175; envelope-from=prabahy@gmail.com;
helo=mail-we0-f175.google.com;
Received: from mail-we0-f175.google.com ([74.125.82.175])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1VrA4I-0008LG-Vz
for bitcoin-development@lists.sourceforge.net;
Thu, 12 Dec 2013 17:29:00 +0000
Received: by mail-we0-f175.google.com with SMTP id t60so768347wes.6
for <bitcoin-development@lists.sourceforge.net>;
Thu, 12 Dec 2013 09:28:52 -0800 (PST)
X-Received: by 10.194.173.163 with SMTP id bl3mr7714436wjc.10.1386869332423;
Thu, 12 Dec 2013 09:28:52 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.161.197 with HTTP; Thu, 12 Dec 2013 09:28:32 -0800 (PST)
In-Reply-To: <CANEZrP1gDxcKO8z4hgM9BJU6-+Ft0oaiCZjqjN4MxGEJCgs5Ng@mail.gmail.com>
References: <CANEZrP1gDxcKO8z4hgM9BJU6-+Ft0oaiCZjqjN4MxGEJCgs5Ng@mail.gmail.com>
From: Paul Rabahy <prabahy@gmail.com>
Date: Thu, 12 Dec 2013 12:28:32 -0500
Message-ID: <CADu7o8MXuUVrRP0vsvEkPLJ4f=2pC6V7W3hYE0jCVDRKmvqu8A@mail.gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=089e013c6220e8bbfc04ed59ad7c
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information. [URIs: github.com]
-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
(prabahy[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-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: 1VrA4I-0008LG-Vz
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Merge avoidance and P2P connection
encryption
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: Thu, 12 Dec 2013 17:29:00 -0000
--089e013c6220e8bbfc04ed59ad7c
Content-Type: text/plain; charset=ISO-8859-1
First off, nice article. Very clear and informative.
I don't know if this is the best place to post this, but it seems related
to me.
As more wallets implement BIP32, I believe that bitcoin wallets should
begin to encourage people to use
https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#recurrent-business-to-business-transactions-mi0style
address instead of traditional addresses. In the end, this would
improve privacy because users never need to merge coin if they had one of
these "super addresses".
In addition, "super addresses" would fit nicely into BIP70. Right now, the
PaymentDetails message allows the merchant to provide multiple outputs. If
instead the PaymentDetails provide 1 traditional output (for reverse
compatibility) and 1 "super address", the payment could be broken into as
many pieces as is needed to match unspent outputs already in the customers
wallet. Finally, the refund_to address in Payment could also be upgraded to
a "super address" to enhance privacy there.
I am not sure if there is a large memory requirement for "super addresses",
but to me, it seems that a lot of these privacy enhancing possibilities
will be simple to implement once BIP32 is widely deployed.
On Thu, Dec 12, 2013 at 11:03 AM, Mike Hearn <mike@plan99.net> wrote:
> I wrote an article intended for a broad/non-developer audience on a few
> Bitcoin privacy topics:
>
> - P2P connection encryption
> - Address re-use/payment protocol
> - CoinJoin and merge avoidance
>
> I don't think there's anything much new here for people who were involved
> with the BIP70 design discussions, but it may prove a useful resource when
> talking about privacy features in the payment protocol. Specifically the
> ability to request multiple outputs and submit multiple transactions that
> satisfy them. The article elaborates on how to use that feature to achieve
> some useful privacy outcomes.
>
> I also analyze what using SSL for P2P connections would buy us and what it
> wouldn't.
>
> https://medium.com/p/7f95a386692f
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--089e013c6220e8bbfc04ed59ad7c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>First off, nice article. Very clear and informative.<=
br><br>I don't know if this is the best place to post this, but it seem=
s related to me.<br><br>As more wallets implement BIP32, I believe that bit=
coin wallets should begin to encourage people to use <a href=3D"https://git=
hub.com/bitcoin/bips/blob/master/bip-0032.mediawiki#recurrent-business-to-b=
usiness-transactions-mi0">https://github.com/bitcoin/bips/blob/master/bip-0=
032.mediawiki#recurrent-business-to-business-transactions-mi0</a> style add=
ress instead of traditional addresses. In the end, this would improve priva=
cy because users never need to merge coin if they had one of these "su=
per addresses".<br>
<br>In addition, "super addresses" would fit nicely into BIP70. R=
ight now, the PaymentDetails message allows the merchant to provide multipl=
e outputs. If instead the PaymentDetails provide 1 traditional output (for =
reverse compatibility) and 1 "super address", the payment could b=
e broken into as many pieces as is needed to match unspent outputs already =
in the customers wallet. Finally, the refund_to address in Payment could al=
so be upgraded to a "super address" to enhance privacy there.<br>
<br></div>I am not sure if there is a large memory requirement for "su=
per addresses", but to me, it seems that a lot of these privacy enhanc=
ing possibilities will be simple to implement once BIP32 is widely deployed=
.<br>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Thu,=
Dec 12, 2013 at 11:03 AM, Mike Hearn <span dir=3D"ltr"><<a href=3D"mail=
to:mike@plan99.net" target=3D"_blank">mike@plan99.net</a>></span> wrote:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">I wrote an article intended for a broad/non-developer audi=
ence on a few Bitcoin privacy topics:<div><br></div><div>- P2P connection e=
ncryption</div><div>- Address re-use/payment protocol</div><div>- CoinJoin =
and merge avoidance</div>
<div><br></div><div>I don't think there's anything much new here fo=
r people who were involved with the BIP70 design discussions, but it may pr=
ove a useful resource when talking about privacy features in the payment pr=
otocol. Specifically the ability to request multiple outputs and submit mul=
tiple transactions that satisfy them. The article elaborates on how to use =
that feature to achieve some useful privacy outcomes.</div>
<div><br></div><div>I also analyze what using SSL for P2P connections would=
buy us and what it wouldn't.</div><div><br></div><div><a href=3D"https=
://medium.com/p/7f95a386692f" target=3D"_blank">https://medium.com/p/7f95a3=
86692f</a><br>
</div>
</div>
<br>-----------------------------------------------------------------------=
-------<br>
Rapidly troubleshoot problems before they affect your business. Most IT<br>
organizations don't have a clear picture of how application performance=
<br>
affects their revenue. With AppDynamics, you get 100% visibility into your<=
br>
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynami=
cs Pro!<br>
<a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D84349831&iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D84349831&iu=3D/4140/ostg.clktrk</a><br>___________________=
____________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br></div>
--089e013c6220e8bbfc04ed59ad7c--
|
