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

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