path: root/51/932203c4aa1105d5a86f1f16bd599a61619dc7

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 <pete@petertodd.org>) id 1Vdmjw-0003Fx-0L
	for bitcoin-development@lists.sourceforge.net;
	Tue, 05 Nov 2013 19:56:40 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.148.113 as permitted sender)
	client-ip=62.13.148.113; envelope-from=pete@petertodd.org;
	helo=outmail148113.authsmtp.com; 
Received: from outmail148113.authsmtp.com ([62.13.148.113])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1Vdmju-0000Ls-En for bitcoin-development@lists.sourceforge.net;
	Tue, 05 Nov 2013 19:56:39 +0000
Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237])
	by punt10.authsmtp.com (8.14.2/8.14.2) with ESMTP id rA5JuOxL099590; 
	Tue, 5 Nov 2013 19:56:24 GMT
Received: from petertodd.org (petertodd.org [174.129.28.249])
	(authenticated bits=128)
	by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id rA5JuHu1053049
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
	Tue, 5 Nov 2013 19:56:19 GMT
Date: Tue, 5 Nov 2013 14:56:16 -0500
From: Peter Todd <pete@petertodd.org>
To: Ittay <ittay.eyal@cornell.edu>
Message-ID: <20131105195616.GA14382@petertodd.org>
References: <CABT1wWkOukEzxK5fLbnA4ZgJGN1hb_DMteCJOfA13FE_QZCi=Q@mail.gmail.com>
	<20131105170541.GA13660@petertodd.org>
	<20131105171445.GA13710@petertodd.org>
	<CABT1wW=XgDfxfxMxyjcNhtNTzXkGLtgSLz3JJcUAq9ywgpymyg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="yrj/dFKFPuw6o+aM"
Content-Disposition: inline
In-Reply-To: <CABT1wW=XgDfxfxMxyjcNhtNTzXkGLtgSLz3JJcUAq9ywgpymyg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 57264ed1-4654-11e3-94fa-002590a135d3
X-AuthReport-Spam: If SPAM / abuse - report it at:
	http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
	bgdMdgcUFloCAgsB AmUbWl1eVVt7W2M7 ag1VcwRfa1RMVxto
	VEFWR1pVCwQmQ20E fFtmFxhycgZGfHc+ YEdkVnUVWUN4c0Io
	Fk9JEWsDYXphaTUc TUlcIVJJcANIexZF O1F8UScOLwdSbGoL
	NQ4vNDcwO3BTJTpY RgYVKF8UXXNDNB8E DwgYGi0oBkQBD2B7
	NxU6IV5UAEFZKEwz KlZpQl8cPR4JCm8W GkBLASlWb0UBXScw DQReUQh2
X-Authentic-SMTP: 61633532353630.1024:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 174.129.28.249/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
	anti-virus system.
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 SPF_PASS               SPF: sender matches SPF record
	0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
	See
	http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
	for more information. [URIs: ghash.io]
X-Headers-End: 1Vdmju-0000Ls-En
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
	Gavin Andresen <gavin@bitcoinfoundation.org>,
	Emin =?iso-8859-1?B?R/xu?= Sirer <egs@systems.cs.cornell.edu>
Subject: Re: [Bitcoin-development] BIP proposal - patch to raise selfish
 mining threshold.
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: Tue, 05 Nov 2013 19:56:40 -0000


--yrj/dFKFPuw6o+aM
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Nov 05, 2013 at 12:43:15PM -0500, Ittay wrote:
> On Tue, Nov 5, 2013 at 12:14 PM, Peter Todd <pete@petertodd.org> wrote:
>=20
> > On Tue, Nov 05, 2013 at 12:05:41PM -0500, Peter Todd wrote:
> > > On Tue, Nov 05, 2013 at 11:56:53AM -0500, Ittay wrote:
> >
> > Oh, and I don't want to give the wrong impression: there's no need to
> > rush to get this problem fixed. Even if someone wanted to launch an
> > attack right now, with a fair amount of resources, there's a lot of
> > counter-measures based on human intervention that can definitely stop
> > the attack in the short-term
>=20
>=20
> The attack can be easily hidden. And be sure that before today, today,
> and after today, very smart people are at their computer planning attacks
> on Bitcoin. Exploits must be published and fixed FAST.

Not this exploit.

Here's a perfectly plausible worst-case scenario, that could be
happening right now: RAND High Frequency Trading Corp (a subsidiary of
General Evil) has a globe-spanning low-latency network of fiber,
line-of-sight microwave, and some experimental line-of-site neutrino
links criss-crossing the globe. They can get data to and from any point
on this planet faster than anyone else. Of course, in addition to their
spectacular network they have an immense amount of computing power, as
well as exotic overclocked liquid nitrogen bathed CPU's that run at
clockspeeds double what commercial hardware can do; in short, they have
access to scalar performance no-one else has. Of course, they like to
keep a healthy reserve so, 99% of all this fancy gear is constantly
idle. Whatever, they can afford it.

RAND just hired a bunch of fresh MIT graduates, the best of the best.
Problem is the best of the best tends to make not so best mistakes, so
RAND figures a Training Exercise is in order. Fortunately for them the NSA =
(a
subsidiary of General Evil) slipped a rootkit into my keyboard a week or
so ago - probably that time when I woke up in that farmers field with a
*splitting* headache - and are reading what I'm typing right now.

I go on to explain how an excellent training exercise for these fresh
MIT graduates would be to implement this nifty attack some Cornell
researchers came up with. It's really simple, elegant even, but to do it
best what you really want is the kind of low-latency network a
high-frequency-trading corporation would have. I then point out how a
good training exercise ideally is done in a scenario where there is
genuine risk and reward, but where the worst-case consequences are
manageable - new hires to tend to screw up. (I then go on to explain my
analog electronics background, and squeeze in some forced anecdote about
how I blew up something worth a lot of money owned by my employers at
some point in the distant past)

Unfortunately for the operators of BTC Guild, one of these new MIT grads
happens to have a: passed General Evil's psych screening with flying
colors, and b: have spent too much time around the MIT Kidnappng Club.
He decides it'd be easier to just kidnap the guy running BTC Guild than
fill out the paperwork to borrow RAND's FPGA cluster, so he does.

As expected the attack runs smoothly: with 30% of the hashing power,
neutrino burst generator/encoders's rigged around the globe to fire the
moment another pool gets a block, and the odd DoS attack for fun, they
quickly make a mockery of the Bitcoin network, reducing every other
miners profitability to zero in minutes. The other miners don't have a
hope: they're blocks have to travel the long way, along the surface of
the earth, while RAND's blocks shave off important milliseconds by
taking the direct route.


Of course, this doesn't go unnoticed, er, eventualy: 12 hours later the
operators of GHash.IO, Eligius, slush, Bitminter, Eclipse and ASICMiner
open their groggy eyes and mutter something about how that simulcast
Tuesday party really shouldn't have had an open bar... or so much coke.

They don't even notice that the team from BTC Guild has vanished, but
they do notice a YouTube video of Gavin right on bitcoin.org doing his
best Spock impression, er, I mean appealing for calm and promising that
Top Men are working on the issue of empty blocks as we speak. Meanwhile
CNN's top headline reads "IS THIS THE END OF BITCOIN?!?!"

It takes another hour for the Aspirin's to finally kick in, but
eventually get all get on IRC and start trying to resolve the issue -
seems that whenever any of them produce a block, somehow by incredible
coincidence someone else finds another block first. After a few rounds
of this they're getting suspicious. (if they weren't all so hung-over
they might have also found suspicious the fact that whenever they found
a block they saw a sudden blue flash - Cherenkov radiation emitted when
those neutrino's interacted with the vitreous humour in their eyeballs)

It's quickly realized that "somehow" BTC Guild isn't affected...
GHash.IO and Eligius, 22% and 13% of the hashing power respectively,
decide to try a little experiment: they peer to each other and only each
other through an encrypted tunnel and... hey, no more lucky blocks!
slush, 7% of the hashing power is invited to the peering group next,
followed by Bitminter, 6%, and Eclipse, 2%, and finally ASICMiner, 1%,
for a grand total of... 51% of the hashing power!

Of course, just creating blocks isn't useful for users, they need to be
distributed too, so someone quickly writes up a "one-way firewall" patch
that allows the group's blocks to propagate to the rest of the network.
Blocks created by anyone else are ignored.

It takes a few more hours, but eventually the attacker seems to run out
of blocks, and transaction processing returns to normal, albeit a little
slow. (20 min block average) Of course, soon there's a 3,000 post thread
on bitcointalk complaining about the "centralized pool cartel", but
somehow life goes on.

The next day Gavin goes on CNN, and gives a lovely interview about how
the past two days events show how the strength of the Bitcoin network is
in the community. For balance they interview this annoying "Peter Todd"
guy from "Keep Bitcoin Free!" who blathers on about how relying on
altruism or something will doom the Bitcoin network in the long run.
After the interview Gavin respectfully points out that maybe next time
they find a so called "developer" with a ratio of bitcointalk posts to
actual lines of code in the Bitcoin git repository better than one
hundred to one. The producer just wishes that "Mike Hearn" guy was
available; at least he's got a sense of fashion, sheesh!


Anyway, I'm out of space for my little story, but yeah, the ending
involves a group of now-rich pool operators who decide to start a large
financial services and data networking company, oh, and time-travel...


> Nevertheless, I agree  that, as you say, we must not rush it. Look at the
> BIP, find if we missed anything, and let's discuss it.

Indeed.

Quite seriously, your attack is a serious long-term risk, but in the
short term the social dynamics of Bitcoin are such that it's just not a
show-stopping risk. At worst some miners will lose a bunch of money -
that's something that's happened before with the March chain fork, and
sure enough Bitcoin survived just fine.

> > In addition, keep in mind
> > that this attack is very easy to detect, so if one is actually launched
> > we will know immediately and can start taking direct counter-measures at
> > that time.
> >
>=20
> Not really. Please see the discussion section in our paper.

You can hide *who* is the attacker - you can't hide the fact that an
attack is happening if done on a meaningful scale.

> > That Gregory Maxwell so quickly identified a flaw in this proposed
> > solution suggests we should proceed carefully.
> >
>=20
> There is no flaw. You were just reiterating that the solution does not gi=
ve
> us the 51% percent security you thought you had before. We showed that
> we're not getting this back, I'm afraid.

That's not what we're concerned about - what we're concerned about is
that your BIP doesn't discuss the issue, and you didn't seem to be aware
of it. That suggests that the analysis is incomplete. There's no
pressing need to rush changes, as explained above by example, so we're
best off understanding the issue thoroughly first.

There's a whole spectrum of potential solutions that haven't been
discussed - I myself have two approaches I'm working on that may solve
this problem in ways you haven't (publicly) considered. I'm sure there
are many others out there.

--=20
'peter'[:-1]@petertodd.org
00000000000000005144f6a7109b9f8543880a0a5f85a054ec53966bc2daa24c

--yrj/dFKFPuw6o+aM
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBCAAGBQJSeU1gAAoJEBmcgzuo5/CFi6IH/Am6Xk+JsQG8C7pTMnL5cj4d
rZefqErUVEq/gvKvg3SQtgI6WNRG5ZlJUIOh3FAswG2j/CalrbpzeH2htkzztZH1
DuKwQaAfcyHtDENoUQoXpEB0s1XsR70MnqWfrPrCwfNNyYckOaGeGkXE7kDbLQrg
ngQhogrRANFONQZm78zaCflfPvyc/N+CM234weHq9ciM3gypWriL9OMH3QkxjJlL
yi1K6WChJpZfjlhF9LXsh+HAJNrkvVrKhDEWnxFME4j21c3dUhwNvy5uTRq0C57t
cR2f/1ZJmW86QwqJSq1WKQnvK4DkoDJ+4Qn/u3vXm8WcxO/XvTt93TjhcjG/gf8=
=u1c7
-----END PGP SIGNATURE-----

--yrj/dFKFPuw6o+aM--