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
|
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 <john.dillon892@googlemail.com>) id 1UsVcK-0002ka-Qc
for bitcoin-development@lists.sourceforge.net;
Fri, 28 Jun 2013 10:09:24 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of googlemail.com
designates 74.125.83.53 as permitted sender)
client-ip=74.125.83.53;
envelope-from=john.dillon892@googlemail.com;
helo=mail-ee0-f53.google.com;
Received: from mail-ee0-f53.google.com ([74.125.83.53])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UsVcI-0000iS-Lj
for bitcoin-development@lists.sourceforge.net;
Fri, 28 Jun 2013 10:09:24 +0000
Received: by mail-ee0-f53.google.com with SMTP id c41so939954eek.40
for <bitcoin-development@lists.sourceforge.net>;
Fri, 28 Jun 2013 03:09:16 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.14.211.67 with SMTP id v43mr13140194eeo.55.1372414156310;
Fri, 28 Jun 2013 03:09:16 -0700 (PDT)
Received: by 10.223.12.131 with HTTP; Fri, 28 Jun 2013 03:09:16 -0700 (PDT)
In-Reply-To: <CANEZrP2gv2qus1CKTTSFMYcNQDbrSctKmA03YE_eZFDTQsQhXw@mail.gmail.com>
References: <1372353053.10405.140661249237317.77984E1F@webmail.messagingengine.com>
<CAAS2fgTka6Dw94V0-vHBHxG=zadu9EmhKmfVm7Y_dQUUgrTf6w@mail.gmail.com>
<CANEZrP2gv2qus1CKTTSFMYcNQDbrSctKmA03YE_eZFDTQsQhXw@mail.gmail.com>
Date: Fri, 28 Jun 2013 10:09:16 +0000
Message-ID: <CAPaL=UV6vhVK6W0FiVoqM+=9C9TAUXVKwbuynq3NZYFzFR8TTQ@mail.gmail.com>
From: John Dillon <john.dillon892@googlemail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: text/plain; charset=ISO-8859-1
X-Spam-Score: -1.4 (-)
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
(john.dillon892[at]googlemail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
digit (john.dillon892[at]googlemail.com)
-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: 1UsVcI-0000iS-Lj
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposal: MultiBit as default desktop
client on bitcoin.org
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, 28 Jun 2013 10:09:25 -0000
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Fri, Jun 28, 2013 at 9:05 AM, Mike Hearn <mike@plan99.net> wrote:
>> I see some of the the other things that were concerning for me at the
>> time are still uncorrected though, e.g. no proxy support (so users
>> can't follow our recommended best practices of using it with Tor),
>
> Yeah. That's not the primary privacy issue with bitcoinj though. I'm
> much, much more concerned about leaks via the block chain than the
> network layer. Especially as Tor is basically a giant man in the
> middle, without any kind of authentication you can easily end up
> connected to a sybil network without any idea. I'd be surprised if Tor
> usage was very high amongst Bitcoin users.
Tor does not act as a particularly effective man in the middle for nodes
that support connections to hidden services because while your
connections to standard Bitcoin nodes go through your exit node, the
routing path for each hidden service peer is independent. Having said
that we should offer modes that send your self-generated transactions
out via Tor, while still maintaining non-Tor connections.
Anyway Sybil attacks aren't all that interesting if you are the one
sending the funds, and receivers are reasonably well protected simply
because generating false confirmations is extremely expensive and very
difficult to do quickly. After all, you always make the assumption that
nearly all hashing power in existence is honest when you talk about
replace-by-fee among other things, and that assumption naturally leads
to the conclusion that generating false confirmations with a sybil
attack would take more than long enough that the user would be
suspicious that something was wrong long before being defrauded.
I'd be surprised if anyone has ever bothered with a false confirmation
sybil attack. I wouldn't be the slightest bit surprised if the NSA is
recording all the Bitcoin traffic they can for future analysis to find
true transaction origins. Which reminds me, again, we need node-to-node
connections to be encrypted to at least protect against network-wide
passive sniffiing.
Regarding usage I would be interested to hear from those running Bitcoin
nodes advertising themselves as hidden services.
> It's not a library limitation anyway, it's a case of how best to
> present information to a user who is not familiar with how Bitcoin
> works. "Safe" and "Not safe" is still a rather misleading distinction
> given the general absence of double spends against mempool
> transactions, but it's still a lot more meaningful than "2 confirms"
For what it is worth I ran a double-spend generator a month or so ago
against the replace-by-fee node that Peter setup and I found that a
small number of the double-spends did in fact appear to be mined under
replace-by-fee rules.
Specifically the generator would create a transaction from confirmed
inputs, wait 60-180 seconds (randomized) to allow for full propagation,
and then create a double-spend if the transaction hadn't already been
mined. The transactions were randomized to look like normal traffic,
including occasional bets to Satoshidice and similar for fun. (for the
record the script had no way of knowing if a bet won and would happily
attempt to double-spend wins) Fees for the replacement were power-law
distributed IIRC, with some occasionally set to be quite hefty.
Though possibly just an artifact of unusually slow transaction
propagation it appeared that about 0.25% of hashing power was following
replace-by-fee rules. (not including transactions involving gambling, I
know Eligius and perhaps others block such transactions from their
mempools making double-spends easy to accomplish by including
Satoshidice outputs)
I'm actually surprised by that figure myself given Peter Todd and I
haven't made a serious attempt yet to get miners to use replace-by-fee
rules. An interesting experiment would be to advertise that money is
being given away by such a tx generator in the mining forum, although I
would prefer to see solid mempool support for the "scorched-earth"
double-spend countermeasure first; Peter sounds like he has some great
ideas there, although as usual I am seeing very little in the way of
code. :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJRzWCOAAoJEEWCsU4mNhiPwhgH/ic/OJMCYwdIuEM2ArSAEQRY
l5bqafMYMcC/KE9xqZ1HVkLJ9Zg57MQ8VZw95WOsmRgNA0v1xIoCyREjI84QkCIq
R/hOgS97eJc+XXnPBVoB4Jadq5LQ6jNpJo7cmiLJjCEmE6rTxLZBBT4P3eQw8oIn
WAd7X7utP7/QAkjhaWB9FsfWT8QZseqpSPv8WucRftsRCABurzuD+eSfpRqYwk2z
XBD0zO+EyAtu6hB3dRAFhqnhVfEcOLJCtXpm76WO574H4AZ/8EN+HozLJSUtylCq
j1NZnpj/6pdFh2v5Pid4HEMEvuNNX60u6iXGJ560PUsdKmOh+LEhUBLKd9acJTw=
=QtjI
-----END PGP SIGNATURE-----
|
