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
|
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 <laanwj@gmail.com>) id 1YYgk8-0007KG-Eb
for bitcoin-development@lists.sourceforge.net;
Thu, 19 Mar 2015 20:08:36 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.182 as permitted sender)
client-ip=209.85.212.182; envelope-from=laanwj@gmail.com;
helo=mail-wi0-f182.google.com;
Received: from mail-wi0-f182.google.com ([209.85.212.182])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YYgk6-0001ZD-G6
for bitcoin-development@lists.sourceforge.net;
Thu, 19 Mar 2015 20:08:36 +0000
Received: by wixw10 with SMTP id w10so15598846wix.0
for <bitcoin-development@lists.sourceforge.net>;
Thu, 19 Mar 2015 13:08:28 -0700 (PDT)
X-Received: by 10.194.62.167 with SMTP id z7mr157076205wjr.106.1426795708490;
Thu, 19 Mar 2015 13:08:28 -0700 (PDT)
Received: from amethyst.visucore.com (dhcp-089-098-016-041.chello.nl.
[89.98.16.41])
by mx.google.com with ESMTPSA id ps4sm3333421wjc.31.2015.03.19.13.08.27
(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
Thu, 19 Mar 2015 13:08:27 -0700 (PDT)
Date: Thu, 19 Mar 2015 21:08:25 +0100
From: "Wladimir J. van der Laan" <laanwj@gmail.com>
To: Justus Ranvier <justus.ranvier@monetas.net>,
bitcoin-development@lists.sourceforge.net
Message-ID: <20150319200824.GB31182@amethyst.visucore.com>
References: <550855A2.4080902@monetas.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <550855A2.4080902@monetas.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Spam-Score: -1.6 (-)
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
(laanwj[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-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: 1YYgk6-0001ZD-G6
Subject: Re: [Bitcoin-development] Improving resistance to transaction
origination harvesting
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, 19 Mar 2015 20:08:36 -0000
On Tue, Mar 17, 2015 at 11:26:10AM -0500, Justus Ranvier wrote:
>
> Allow Bitcoin nodes to create authenticated connections with trusted
> peers via CurveCP [2]. Nodes that have at least one CurveCP peer only
> broadcast their transactions to those peers.
The user would have to select trusted peers or rely on a web of trust to
pick them. Experience with other networks such as Retroshare shows that
not only this is a lot of work to use, mistakes are easily made. It
will only protect the privacy of those that know what they're
doing and who they're trusting.
Otherwise, paradoxally this could reduce privacy, as the trusted peers
necessarily know (part of) your identity to be able to exchange keys
out-of-band.
(and in practice most people are easily tricked into adding someone as
'friend', for Retroshare here is a case in which a law firm did this and
thus could sue people for making files available...)
> Use of CurveCP requires both sides of the connection to know each
> other's long term public key. This key can be packaged in a structure
> similar in concept to a Freenet node reference.
Right.
> Users who wish to set up a secure connection between their nodes would
> first use an API command to generate their node references, exchange
> these files, and copy them to the ~/.bitcoin/curvecp directory with a
> .ref extension. The node only accepts CurveCP connections from, and
> attempts CurveCP connection to, peers whose references are present in
> that directory.
Indeed, if the goal is to make a secure connections between nodes that
know and trust each other, this could employ any kind of tunnelling on top
of the P2P protocol. CurveCP would be one option.
As said I'm not convinced this will help with privacy, but this could be
used for whitelisting: trusted nodes could be subjected to fewer DoS
constraints.
> Relationship with Tor:
>
> This proposal would work along with, or independently of Tor usage.
>
> The same network monitoring techniques which can track an originating
> transaction to a particular IP address could do the same thing for a
> node which is listening as a hidden service, and any technique for
> deanonymising hidden services could then identify the point of origin.
Seperating the transaction submission from normal node functionality
would already go a long way, and that can be done without any protocol
changes. The transaction submitter would connect to a few nodes
through Tor and drop off a transaction, then disconnect. It would not
advertise itself as the hidden service, and should also use a different
Tor circuit as the node connections.
This could even work if the normal node functionality does not go
through Tor - although then one'd have to be even more careful about
any kind of residual fingerprinting or timing attacks.
Wladimir
|
