summaryrefslogtreecommitdiff
path: root/8c/c77922556fc91167ba8f74fd7b3ca8fcfd4a1b
blob: 42bd23f8aad4a2167e8f1a1e1f348bf5edac26ad (plain)
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-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <decker.christian@gmail.com>) id 1QpK03-0002V6-Vf
	for bitcoin-development@lists.sourceforge.net;
	Fri, 05 Aug 2011 12:59:39 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.83.47 as permitted sender)
	client-ip=74.125.83.47; envelope-from=decker.christian@gmail.com;
	helo=mail-gw0-f47.google.com; 
Received: from mail-gw0-f47.google.com ([74.125.83.47])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128)
	(Exim 4.76) id 1QpK03-0002Xi-01
	for bitcoin-development@lists.sourceforge.net;
	Fri, 05 Aug 2011 12:59:39 +0000
Received: by gwb11 with SMTP id 11so764281gwb.34
	for <bitcoin-development@lists.sourceforge.net>;
	Fri, 05 Aug 2011 05:59:33 -0700 (PDT)
Received: by 10.142.247.15 with SMTP id u15mr2021487wfh.307.1312549173257;
	Fri, 05 Aug 2011 05:59:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.52.98 with HTTP; Fri, 5 Aug 2011 05:58:53 -0700 (PDT)
In-Reply-To: <1312545697.19584.56.camel@mei>
References: <CAJNQ0svWgFwZrra0gQFpxNLOPXk4RbKygeMUNPEA=k-Wqwa-ZA@mail.gmail.com>
	<201108041038.47396.luke@dashjr.org>
	<CABsx9T2tAeOp6RAb+Zb5zmzdSePZV90Uu=r4mzFc44d6ndbcnQ@mail.gmail.com>
	<CAJNQ0stRrv4Yqf9ENszoXJE8+FpzwXZaGVDP=stZi27x4BRmmg@mail.gmail.com>
	<CA+8xBpd0ud0Jn7Xxfw3C-WCH12WuB7k_W5x00Mj2EidemGoYpQ@mail.gmail.com>
	<1312545697.19584.56.camel@mei>
From: Christian Decker <decker.christian@gmail.com>
Date: Fri, 5 Aug 2011 14:58:53 +0200
Message-ID: <CALxbBHXbgDqZc1W+NJDbD78MP45U_oLkFVed5f3xWmJJGm=gCA@mail.gmail.com>
To: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=00504502cc3438e69f04a9c1ab69
X-Spam-Score: -0.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
	(decker.christian[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: 1QpK03-0002Xi-01
Subject: Re: [Bitcoin-development] Blitcoin? (Black Hat 2011)
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, 05 Aug 2011 12:59:40 -0000

--00504502cc3438e69f04a9c1ab69
Content-Type: text/plain; charset=ISO-8859-1

While I do think that anonymity (or pseudonymity) is a nice feature, I don't
think it deserves the full focus of the developers. The core of the protocol
is about making transactions in a secure and fast way, not allowing
everybody to be anonymous, whether they want to or not. TOR already is a
good options for those that want to stay anonymous, and there is no need to
pull support into the main client, if only a few will use it. I think very
few of the developers actually claimed that Bitcoin is anonymous, and has
never been a big advertising point from the "official" side of Bitcoin,
network analysis has been always known to break anonymity.

I see no need for action from the developer side.

-cdecker

On Fri, Aug 5, 2011 at 2:01 PM, Joel Joonatan Kaartinen <
joel.kaartinen@gmail.com> wrote:

> On Fri, 2011-08-05 at 01:52 -0400, Jeff Garzik wrote:
> > Yes, that is correct.  Bitcoin resends wallet transactions with zero
> > confirmations, and both sent and received transactions fall within the
> > "wallet tx" superset.
> >
> > TBH I had forgotten about the resend on the receiver side, though.
> > It, of course, makes plenty of sense in the context of importing
> > transactions from foreign sources, e.g. receiving transactions via a
> > USB flash drive.
>
> Could every node do the resends? Alternatively, could we implement a TOR
> like tunneling system just for the first leg of the transactions
> (overkill?). Then again, maybe just a TOR gateway if that's desired.
>
> > > Drawok's suggestion about using UDP packets with spoofed sender
> addresses is
> > > interesting, as UDP has another advantage; you can open up an "inbound"
> UDP
> > > port on almost any NAT router without any UPNP magic: just send out an
> UDP
> > > packet, the router will wait a certain time for answers (on a mapped
> port
> > > number) and relay these back.
>
> This is a nice idea but sounds rather unreliable.
>
> > Well, it -is- possible to implement TCP over UDP <grin>  The TCP
> > connection sequence over UDP helps to work against spoofing, while UDP
> > helps to open an inbound UDP port as you describe.
>
> There's already an implementation of this, called UTP. If we do decide
> that using UDP is worthwhile, this library is probably better than
> implementing something ourselves.
>
> - Joel
>
>
>
>
> ------------------------------------------------------------------------------
> BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
> The must-attend event for mobile developers. Connect with experts.
> Get tools for creating Super Apps. See the latest technologies.
> Sessions, hands-on labs, demos & much more. Register early & save!
> http://p.sf.net/sfu/rim-blackberry-1
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

--00504502cc3438e69f04a9c1ab69
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

While I do think that anonymity (or pseudonymity) is a nice feature, I don&=
#39;t think it deserves the full focus of the developers. The core of the p=
rotocol is about making transactions in a secure and fast way, not allowing=
 everybody to be anonymous, whether they want to or not. TOR already is a g=
ood options for those that want to stay anonymous, and there is no need to =
pull support into the main client, if only a few will use it. I think very =
few of the developers actually claimed that Bitcoin is anonymous, and has n=
ever been a big advertising point from the &quot;official&quot; side of Bit=
coin, network analysis has been always known to break anonymity.<br>

<br>I see no need for action from the developer side.<br><br>-cdecker<br><b=
r><div class=3D"gmail_quote">On Fri, Aug 5, 2011 at 2:01 PM, Joel Joonatan =
Kaartinen <span dir=3D"ltr">&lt;<a href=3D"mailto:joel.kaartinen@gmail.com"=
>joel.kaartinen@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;"><div class=3D"im">On Fri, 2011-08-05 at 01:=
52 -0400, Jeff Garzik wrote:<br>
&gt; Yes, that is correct. =A0Bitcoin resends wallet transactions with zero=
<br>
&gt; confirmations, and both sent and received transactions fall within the=
<br>
&gt; &quot;wallet tx&quot; superset.<br>
&gt;<br>
&gt; TBH I had forgotten about the resend on the receiver side, though.<br>
&gt; It, of course, makes plenty of sense in the context of importing<br>
&gt; transactions from foreign sources, e.g. receiving transactions via a<b=
r>
&gt; USB flash drive.<br>
<br>
</div>Could every node do the resends? Alternatively, could we implement a =
TOR<br>
like tunneling system just for the first leg of the transactions<br>
(overkill?). Then again, maybe just a TOR gateway if that&#39;s desired.<br=
>
<div class=3D"im"><br>
&gt; &gt; Drawok&#39;s suggestion about using UDP packets with spoofed send=
er addresses is<br>
&gt; &gt; interesting, as UDP has another advantage; you can open up an &qu=
ot;inbound&quot; UDP<br>
&gt; &gt; port on almost any NAT router without any UPNP magic: just send o=
ut an UDP<br>
&gt; &gt; packet, the router will wait a certain time for answers (on a map=
ped port<br>
&gt; &gt; number) and relay these back.<br>
<br>
</div>This is a nice idea but sounds rather unreliable.<br>
<div class=3D"im"><br>
&gt; Well, it -is- possible to implement TCP over UDP &lt;grin&gt; =A0The T=
CP<br>
&gt; connection sequence over UDP helps to work against spoofing, while UDP=
<br>
&gt; helps to open an inbound UDP port as you describe.<br>
<br>
</div>There&#39;s already an implementation of this, called UTP. If we do d=
ecide<br>
that using UDP is worthwhile, this library is probably better than<br>
implementing something ourselves.<br>
<font color=3D"#888888"><br>
- Joel<br>
</font><div><div></div><div class=3D"h5"><br>
<br>
<br>
---------------------------------------------------------------------------=
---<br>
BlackBerry&amp;reg; DevCon Americas, Oct. 18-20, San Francisco, CA<br>
The must-attend event for mobile developers. Connect with experts.<br>
Get tools for creating Super Apps. See the latest technologies.<br>
Sessions, hands-on labs, demos &amp; much more. Register early &amp; save!<=
br>
<a href=3D"http://p.sf.net/sfu/rim-blackberry-1" target=3D"_blank">http://p=
.sf.net/sfu/rim-blackberry-1</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>
</div></div></blockquote></div><br>

--00504502cc3438e69f04a9c1ab69--