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; 
MIME-Version: 1.0
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
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposal: MultiBit as default desktop
 client on bitcoin.org
Precedence: list

-----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-----