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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1Vr8k5-0003BG-Kd
for bitcoin-development@lists.sourceforge.net;
Thu, 12 Dec 2013 16:04:01 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.53 as permitted sender)
client-ip=209.85.219.53; envelope-from=mh.in.england@gmail.com;
helo=mail-oa0-f53.google.com;
Received: from mail-oa0-f53.google.com ([209.85.219.53])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Vr8k4-0004ga-Ei
for bitcoin-development@lists.sourceforge.net;
Thu, 12 Dec 2013 16:04:01 +0000
Received: by mail-oa0-f53.google.com with SMTP id m1so656442oag.40
for <bitcoin-development@lists.sourceforge.net>;
Thu, 12 Dec 2013 08:03:55 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.182.213.97 with SMTP id nr1mr5963259obc.48.1386864235067;
Thu, 12 Dec 2013 08:03:55 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.76.92.72 with HTTP; Thu, 12 Dec 2013 08:03:55 -0800 (PST)
Date: Thu, 12 Dec 2013 08:03:55 -0800
X-Google-Sender-Auth: U26ksEjY1CBvODZOoNT_yCdLfhE
Message-ID: <CANEZrP1gDxcKO8z4hgM9BJU6-+Ft0oaiCZjqjN4MxGEJCgs5Ng@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a11c20afc15484d04ed587eb4
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
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: medium.com]
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: 1Vr8k4-0004ga-Ei
Subject: [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 16:04:01 -0000
--001a11c20afc15484d04ed587eb4
Content-Type: text/plain; charset=UTF-8
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
--001a11c20afc15484d04ed587eb4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<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">https://medium.com/p/7f95a386692f</a><br></di=
v>
</div>
--001a11c20afc15484d04ed587eb4--
|
