Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: =?utf-8?Q?Rune_Kj=C3=A6r_Svendsen?= <runesvend@gmail.com>
In-Reply-To: <55FCC8B5.9070906@openbitcoinprivacyproject.org>
Date: Sat, 19 Sep 2015 17:45:49 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <4424FA4D-C84F-43DD-BA7F-BAC2D570A373@gmail.com>
References: <5D55F6EC-801B-4607-882F-B76CF57298B1@gmail.com>
	<55FC6951.9010704@gmail.com>
	<A16FDC0B-877F-47F1-A631-77F46251BB07@gmail.com>
	<55FCC8B5.9070906@openbitcoinprivacyproject.org>
To: Justus Ranvier <justus@openbitcoinprivacyproject.org>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Hash of UTXO set as consensus-critical
Precedence: list

We need to distinguish between two different things here:

1) A 51% attack, where the majority of mining power is *malicious* =
(hence =E2=80=9Cattack=E2=80=9D)

and

2) A fork that exists because of a disagreement in the network, with =
total mining power split in two camps, each camp mining peacefully on =
their own chain

These are two very different scenarios.

Some claim that including the UTXO set hash in the block creates a =
vulnerability where miners can include the wrong UTXO hash, and mine on =
that, but this is only possible if a 51% attack is in effect. And if a =
51% attack is in effect, it=E2=80=99s a moot point, because Bitcoin is =
useless anyway, because that 51% malicious mining power could just as =
well be used for mining empty blocks on top of the official chain. Or =
blocks containing randomly generated transactions, without confirming =
any legitimate transactions. This is why we say that a majority of =
honest miners is a hard requirement for Bitcoin. A majority of dishonest =
miners can only be circumvented through centralisation, and then we =
don=E2=80=99t have Bitcoin any longer.

Scenario 2 is unproblematic regardless of whether we include the UTXO =
hash in the block (and make it consensus-critical) or not, since the =
majority mining power on either chain isn=E2=80=99t malicious.

It is correct that if you=E2=80=99re a full node, and a 51% attack is in =
effect, you are able to verify that miners are honest (ie. you know =
whether a 51% attack is in effect or not). But this doesn=E2=80=99t =
change the fact that the Bitcoin network is unreliable, at best, when a =
majority of mining power is used for malicious purposes.


/Rune


> On 19 Sep 2015, at 04:30, Justus Ranvier via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>=20
> On 18/09/15 15:17, Rune Kj=C3=A6r Svendsen via bitcoin-dev wrote:
>> Bitcoin does not function if the majority of mining power is =
dishonest. There is no way around that. It=E2=80=99s how proof-of-work =
functions.
>=20
>=20
> None of those statements are true.
>=20
> If a majority of Bitcoin miners are mining invalid blocks, then they
> aren't Bitcoin miners any more and are no longer relevant to the =
Bitcoin
> consensus.
>=20
> There does exist a problem that light clients aren't always able to =
tell
> the difference between chains that are valid and chains that are not
> valid, but it's is possible to create simple proofs that would do so:
>=20
> https://gist.github.com/justusranvier/451616fa4697b5f25f60
>=20
>=20
> If those changes would be implemented, then any node that knew a chain
> was invalid could produce a compact proof that anyone else in the
> network could verify, regardless of how much proof of work was used to
> create the invalid chain.
>=20
> Committed UTXO sets would need safe to rely upon if a similar set of
> proofs that a particular set was invalid existed.
>=20
> --=20
> Justus Ranvier
> Open Bitcoin Privacy Project
> http://www.openbitcoinprivacyproject.org/
> justus@openbitcoinprivacyproject.org
> E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623
> <0xEAD9E623.asc>_______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev