path: root/69/dc2c9afbc21ebfeb00b01e2ede2ed8a370d6ad

Return-Path: <pete@petertodd.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 71524E2A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 28 Dec 2015 20:02:29 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outmail149112.authsmtp.co.uk (outmail149112.authsmtp.co.uk
	[62.13.149.112])
	by smtp1.linuxfoundation.org (Postfix) with ESMTP id 3CA10177
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 28 Dec 2015 20:02:28 +0000 (UTC)
Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232])
	by punt22.authsmtp.com (8.14.2/8.14.2/) with ESMTP id tBSK2QKF094907;
	Mon, 28 Dec 2015 20:02:26 GMT
Received: from muck (S0106e091f5827ad2.ok.shawcable.net [24.71.232.17])
	(authenticated bits=128)
	by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id tBSK2LIO015466
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
	Mon, 28 Dec 2015 20:02:24 GMT
Date: Mon, 28 Dec 2015 12:02:21 -0800
From: Peter Todd <pete@petertodd.org>
To: Emin =?iso-8859-1?B?R/xu?= Sirer <el33th4x0r@gmail.com>
Message-ID: <20151228200221.GD12298@muck>
References: <20151219184240.GB12893@muck>
	<CAAcC9yvh2ma2dFhNDEKs7vfXyQF9L+T0YtRvOsJ15AbfVti=cw@mail.gmail.com>
	<219f125cee6ca68fd27016642e38fdf1@xbt.hk>
	<CAAcC9ys_t7X0WpQ8W3577M8GLiA5sPV2F1BJ9qZbnMkE-1j3+Q@mail.gmail.com>
	<aff8da46a69bdd7ef92ca87725866a5c@xbt.hk>
	<CAPkFh0vNECi1OmBwki+8NNAQbe6EG2FEE4RR5z=kYVLLDFHUXg@mail.gmail.com>
	<20151220132842.GA25481@muck>
	<CAPkFh0t-+WhZYVLyT_auLa87zAATNOH=CpU4S5H=n6S1wmZ-oQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="ZmUaFz6apKcXQszQ"
Content-Disposition: inline
In-Reply-To: <CAPkFh0t-+WhZYVLyT_auLa87zAATNOH=CpU4S5H=n6S1wmZ-oQ@mail.gmail.com>
X-Server-Quench: ea20f452-ad9d-11e5-829e-00151795d556
X-AuthReport-Spam: If SPAM / abuse - report it at:
	http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
	aAdMdAoUHFAXAgsB AmMbWVReUF97W2Y7 aQ5PagRDYElMQQRt
	T01BRU1TWkEaYmcD emdhUhh3cwNANn95 bEdqECUKXkQscUN/
	Xx8AHDkbZGY1bX0X UkkNagNUcQZLeRZA PlV6Uj1vNG8XDSg5
	AwQ0PjZ0MThBHWxq T0kLIF8eCVoMVjA9 V1geHThnF0kCTCZ7
	MB06Kl4bGEoQNEp6 OEc9UFkbWwA8
X-Authentic-SMTP: 61633532353630.1037:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 24.71.232.17/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
	anti-virus system.
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
	autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] We need to fix the block withholding attack
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Dec 2015 20:02:29 -0000


--ZmUaFz6apKcXQszQ
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Dec 20, 2015 at 12:00:37PM -0500, Emin G=FCn Sirer via bitcoin-dev =
wrote:
> > In the context of KYC, this techniques would likely hold up in court,
> > which means that if this stuff becomes a more serious problem it's
> > perfectly viable for large, well-resourced, pools to prevent block
> > withholding attacks, in part by removing anonymity of hashing power.
> > This would not be a positive development for the ecosystem.
> >
>=20
> KYC has a particular financial-regulation connotation in Bitcoin circles,
> of which I'm sure you're aware, and which you're using as a spectre.
> You don't mean government-regulated-KYC a la FINCEN and Bitcoin
> exchanges like Coinbase, you are just referring to a pool operator
> demanding to know that its customer is not coming from its competitors'
> data centers.

I mean Knowing Your Customer. The only way to know that a customer is
*not* coming from a competitor's data center is to know their identity,
which is precisely what KYC is.

In the financial world, KYC is used to refer to any time you take steps
to determine the real identity/deanonymize your customers.

> And your prediction doesn't seem well-motivated or properly justified.
> There are tons of conditionals in your prediction, starting with the prem=
ise
> that every single open pool would implement some notion of identity
> checking. I don't believe that will happen. Instead, we will have the big=
ger
> pools become more suspicious of signing up new hash power, which is a
> good thing. And we will have small groups of people who have some reason
> for trusting each other (e.g. they know each other from IRC, conferences,
> etc) band together into small pools. These are fantastic outcomes for
> decentralization.

That's a terrible outcomes for decentralization; we *want* people to be
able to contribute hashing power to the network even if they don't
already have personal connections with existing miners. That's how we
attract new players to the mining industry whose backgrounds are not
correlated with the backgrounds of other miners - exactly what we want
for decentralization.

Keep in mind that access to cheap power and cheap opportunities to get
rid of waste heat is naturally decentralized by physics, economics, and
politics. Basically, the cheapest power, and cheapest ways to get rid of
waste heat, is in the form of unique opportunities that don't have
economies of scale. For example, much of the Chinese hashing power takes
advantage of stranded hydroelectric plants that are located far away
=66rom markets that would otherwise buy that power. These plants are
limited in size by the local rivers and there's no way to make them any
bigger - there's a natural diseconomy of scale involved.

Now, support if you have access to such a hydro plant - maybe a mine in
the middle of nowhere just closed and there's no-one else to sell the
power too. Right now you can buy some hashing equipment(1) and start
earning money immediately by pointing it at a pool of your choice. If
that pool fucks up, it's really easy for you to change a few lines in
your configs and point that hashing power to a different pool.

However if block withholding attacks continue and kill off open access
pools the process becomes much more arduous. Chances are you won't even
bother, and Bitcoin will end up with one less decentralized
miner.


1) If access to hashing equipment becomes a limiting factor/fails to
improve, Bitcoin itself will likely have to switch PoW functions to
succeed as a decentralized system.

> Secondly, DRM tech can also easily be used to prevent block withholding
> > attacks by attesting to the honest of the hashing power. This is being
> > discussed in the industry, and again, this isn't a positive development
> > for the ecosystem.
> >
>=20
> DRM is a terrible application. Once again, I see that you're trying to use
> those
> three letters as a spectre as well, knowing that most people hate DRM, but
> keep in mind that DRM is just an application -- it's like pointing to Ado=
be
> Flash
> to taint all browser plugins.
>=20
> The tech behind DRM is called "attestation," and it provides a technical
> capability not possible by any other means. In essence, attestation can
> ensure that
> a remote node is indeed running the code that it purports to be running.
> Since
> most problems in computer security and distributed systems stem from not
> knowing what protocol the attacker is going to follow, attestation is the
> only
> technology we have that lets us step around this limitation.
>
> It can ensure, for instance,
>   - that a node purporting to be Bitcoin Core (vLatest) is indeed running=
 an
> unadulterated, latest version of Bitcoin Core
>   - that a node claiming that it does not harvest IP addresses from SPV
> clients indeed does not harvest IP addresses.
>   - that a cloud hashing outfit that rented out X terahashes to a user did
> indeed rent out X terahashes to that particular user,
>   - that a miner operating on behalf of some pool P will not misbehave and
> discard perfectly good blocks
> and so forth. All of these would be great for the ecosystem. Just getting
> rid
> of the cloudhashing scams would put an end to a lot of heartache.

Again, lets look at it from the perspective of someone with access to
cheap power.

With DRM tech a likely implementation is the equipment manufacturer/pool
operator sells you a locked down, tamper-resistant, box that only can
send hashing power to a specific pool. 21 for example has been
investigating this model. If such equipment is common, even though the
guy with a hydro plant in Siberia is physically and politically highly
decentralized, the control of the blocks created is highly centralized,
rendering his contribution to the network's decentralization moot.

At best we might get general purpose attestation, but implementing that
vs. locked down, single pool, boxes is more expensive and slower to
market. Even then, we'd be much more likely to get fragile and
difficult-to-reverse-engineer hashing equipment that's always going to
be easier to add backdoors too.

We're better off with an ecosystem where DRM tech like attestation isn't
needed at all.

As for cloud hashing... those scams have mostly died off as the market
has become more efficient.

> > GHash.io was not a pure pool - they owned and operated a significant
> > amount of physical hashing power, and it's not at all clear that their %
> > of the network actually went down following that 51% debacle.
> >
>=20
> Right, it's not clear at all that yelling at people has much effect. As m=
uch
> fun as I had going to that meeting with GHash in London to ask them to
> back down off of the 51% boundary, I am pretty sure that yelling at large
> open pools will not scale. We needed better mechanisms for keeping pools
> in check.
>=20
> And Miner's Dilemma (MD) attacks are clearly quite effective. This is a
> time when we should count our blessings, not work actively to render
> them inoperable.

What evidence do you have for them being "clearly quite effective"? Is
there any evidence that they were used against GHash.io for example?

Remember that block withholding attacks give an advantage to those with
access to large amounts of physical hashing power, like GHash.IO did at
that time.

> > Basically you have the pool pick a secret k for each share, and commit
> > to H(k) in the share. Additionally the share commits to a target divider
> > D. The PoW validity rule is then changed from H(block header) < T, to be
> > H(block header) < T * D && H(H(block header) + k) < max_int / D
> >
>=20
> Thanks, this requires a change to the Bitcoin PoW. Good luck with that!

It's not a change to the PoW, just a change to the definition of block
validity; mining hardware does *not* need to change to implement
Luke-Jr's idea. Also, as mentioned elsewhere in this thread, it can be
implemented slowly as a pseudo-soft-fork.

--=20
'peter'[:-1]@petertodd.org
000000000000000001d3c4acb7446f66482fb6aceb087d7601c9e0644cf60e9a

--ZmUaFz6apKcXQszQ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----

iQGrBAEBCACVBQJWgZVLXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwOTRhZmNiYmFkMTBhYTZjODJkZGQ4YWFkMTAyMDIwZTU1
M2Q1MGE2MGI2YzY3OGYvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udy3sQf9G3aF1nJvpv2jr6ovdIZT9XOr
EUjGnPSOohT+QbO1AH95b1OIyL1wLrbwZBlBkwNJkPippnmVCimnNYIup80efJjG
d17DuABENzGqtrWVUV4xIE+IW1D0U33T9bpaA9Uk8b+reB4FznC0/F+5B8N1Pl/K
LwlUDGrZHYXi907ErYtHZkfGzo+sjHiLk34aVDGP/iK7QpVPKTwm6zn0GX+7Ok0X
4NOyTiyr9das3y2h5M7KDJtjIKQGfGTwhTS4vCV7LS5vpQ+NAEZlqOZLuZsa9qDB
OcA/jUswmQo1ngzk+Py+ZOI4Pr6ow9xDFYS42jPM3nvJRdHACe5v1zKUfvWvEg==
=QHnB
-----END PGP SIGNATURE-----

--ZmUaFz6apKcXQszQ--