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
|
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 <mh.in.england@gmail.com>) id 1UsVmk-0003Cu-Lp
for bitcoin-development@lists.sourceforge.net;
Fri, 28 Jun 2013 10:20:10 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.175 as permitted sender)
client-ip=209.85.214.175; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f175.google.com;
Received: from mail-ob0-f175.google.com ([209.85.214.175])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UsVmi-0003bd-Qi
for bitcoin-development@lists.sourceforge.net;
Fri, 28 Jun 2013 10:20:10 +0000
Received: by mail-ob0-f175.google.com with SMTP id xn12so1803194obc.34
for <bitcoin-development@lists.sourceforge.net>;
Fri, 28 Jun 2013 03:20:03 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.176.67 with SMTP id cg3mr6013565obc.65.1372414803437;
Fri, 28 Jun 2013 03:20:03 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.23.36 with HTTP; Fri, 28 Jun 2013 03:20:03 -0700 (PDT)
In-Reply-To: <CAPaL=UV6vhVK6W0FiVoqM+=9C9TAUXVKwbuynq3NZYFzFR8TTQ@mail.gmail.com>
References: <1372353053.10405.140661249237317.77984E1F@webmail.messagingengine.com>
<CAAS2fgTka6Dw94V0-vHBHxG=zadu9EmhKmfVm7Y_dQUUgrTf6w@mail.gmail.com>
<CANEZrP2gv2qus1CKTTSFMYcNQDbrSctKmA03YE_eZFDTQsQhXw@mail.gmail.com>
<CAPaL=UV6vhVK6W0FiVoqM+=9C9TAUXVKwbuynq3NZYFzFR8TTQ@mail.gmail.com>
Date: Fri, 28 Jun 2013 12:20:03 +0200
X-Google-Sender-Auth: 6xfYBW82ZQfbgljsf82H8NB9xBQ
Message-ID: <CANEZrP07LOEDK7wV3afJJN9cEw8xQHoqA=Jk_GrQs2jrpCBC7w@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: John Dillon <john.dillon892@googlemail.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.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.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: 1UsVmi-0003bd-Qi
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:20:10 -0000
I suspect what you saw is mining nodes restarting and clearing their
mempools out rather than an explicit policy of replace by fee.
On Fri, Jun 28, 2013 at 12:09 PM, John Dillon
<john.dillon892@googlemail.com> wrote:
> -----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-----
|
