Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 5CD7E17C7 for ; Sat, 19 Sep 2015 15:45:54 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 87CFE8B for ; Sat, 19 Sep 2015 15:45:53 +0000 (UTC) Received: by wicfx3 with SMTP id fx3so62658223wic.0 for ; Sat, 19 Sep 2015 08:45:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bT4cnXJFB+Exlb5kkcVzbT5r5zXSrMCpNZWHUpC+kFQ=; b=dve6k//CTmivV8af1LeyLEsIftMiyV1+rUdrNlzAVcF5Ix4SlIxyUwB37XEgsb+/M9 UZ0WwZhX3dJp89+Rvn+ID75qktof0JJuX+d7DsQINizIkC2ZDNDjcgzpi7IdEqau4M6A b4dfjjdopfC6YZARRAD8LGqZW5UYSxioLGDRTDCt3xau/fEu7xHFokgp41Bl2WJHWJeQ Ts2ZHcpg4FeIfBZkAK5Wt06vvIXDT8nGSu7SFPcjOUyN+eF5UkqQKPNMJJZN+5uYSMAk YOEwjyImvjlSAq3xb7526h/Q9FiuWu4q1lFC4+o9+wnbcNN7EQMTZjZC6yKlbtTaDeFY qnFA== X-Received: by 10.194.171.129 with SMTP id au1mr14969034wjc.115.1442677552253; Sat, 19 Sep 2015 08:45:52 -0700 (PDT) Received: from [192.168.1.33] ([212.60.121.11]) by smtp.gmail.com with ESMTPSA id gl4sm14542319wjb.29.2015.09.19.08.45.51 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 19 Sep 2015 08:45:51 -0700 (PDT) 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?= 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> <55FCC8B5.9070906@openbitcoinprivacyproject.org> To: Justus Ranvier X-Mailer: Apple Mail (2.2104) X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, 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@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] Hash of UTXO set as consensus-critical X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2015 15:45:54 -0000 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 = 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