From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 5862C7A9 for ; Sat, 28 Jan 2017 18:30:10 +0000 (UTC) X-Greylist: delayed 00:07:12 by SQLgrey-1.7.6 Received: from outmail148098.authsmtp.com (outmail148098.authsmtp.com [62.13.148.98]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 8E8C6156 for ; Sat, 28 Jan 2017 18:30:09 +0000 (UTC) Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232]) by punt21.authsmtp.com (8.14.2/8.14.2/) with ESMTP id v0SIU1YX043513; Sat, 28 Jan 2017 18:30:01 GMT Received: from petertodd.org (ec2-52-5-185-120.compute-1.amazonaws.com [52.5.185.120]) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id v0SITxIf064366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Jan 2017 18:30:00 GMT Received: from [127.0.0.1] (localhost [127.0.0.1]) by petertodd.org (Postfix) with ESMTPSA id E1B434009A; Sat, 28 Jan 2017 18:29:56 +0000 (UTC) Date: Sat, 28 Jan 2017 18:29:32 +0000 In-Reply-To: References: <201701270107.01092.luke@dashjr.org> <20170127212810.GA5856@nex> <201701280403.05558.luke@dashjr.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/signed; boundary="----WBMA1F7SJOO6FKDF7QIWA1G4Z1SPBW"; protocol="application/pgp-signature"; micalg="pgp-sha512" To: Natanael , Bitcoin Protocol Discussion , Natanael via bitcoin-dev , Luke Dashjr , Bitcoin Dev From: Peter Todd Message-ID: X-Server-Quench: c757f4cc-e587-11e6-829f-00151795d556 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdAoUElQaAgsB AmEbWlxeU117WWM7 bghPaBtcak9QXgdq T0pMXVMcUgULeHhJ f0geVB1xcQMIeXxx Z0UsDXdeWxJ+JhVg F0tcEnAHZDJmdWgd WRZFdwNVdQJNdxoR b1V5GhFYa3VsNCMk FAgyOXU9MCtqYBhV WAwAZVIbW0oFGSQ/ AgoPGTwzEEFNbQQL NHQA X-Authentic-SMTP: 61633532353630.1037:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 52.5.185.120/25 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 Subject: Re: [bitcoin-dev] Three hardfork-related BIPs X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2017 18:30:10 -0000 ------WBMA1F7SJOO6FKDF7QIWA1G4Z1SPBW Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 28 January 2017 02:36:16 GMT-08:00, Natanael via bitcoin-dev wrote: >Den 28 jan=2E 2017 05:04 skrev "Luke Dashjr via bitcoin-dev" < >bitcoin-dev@lists=2Elinuxfoundation=2Eorg>: > >Satoshi envisioned a system where full nodes could publish proofs of >invalid >blocks that would be automatically verified by SPV nodes and used to >ensure >even they maintained the equivalent of full node security so long as >they >were >not isolated=2E But as a matter of fact, this vision has proven >impossible, >and >there is to date no viable theory on how it might be fixed=2E As a >result, the >only way for nodes to have full-node-security is to actually be a true >full >node, and therefore the plan of only having full nodes in datacenters >is >simply not realistic without transforming Bitcoin into a centralised >system=2E > > >Beside Zero-knowledge proofs, which is capable of proving much so more >than >just validity, there are multi types of fraud proofs that only rely on >the >format of the blocks=2E Such as publishing the block header + the two >colliding transactions included in it (in the case of double spending), >or >if the syntax or logic is broken then you just publish that single >transaction=2E That's a perfect example of why fraud proofs aren't as secure as expected:= the miner who created such a block wouldn't even give you the data necessa= ry to prove the fraud in the first place=2E What you actually need are validity challenges, where someone makes a chal= lenge claiming that part of the block is invalid=2E A failure to meet the c= hallenge with proof that the rules are followed is considered defacto evide= nce of fraud=2E But validity challenges don't scale well and pose DoS attacks issues; it's= far from clear that they can be implemented in a useful way=2E Even if val= idity challenges work, they also don't solve censorship: a world of nodes i= n large datacenters is a world where it's very easy to force the few Bitcoi= n nodes remaining to follow AML/KYC rules for instance, a risk we wouldn't = be able to mitigate with a PoW change=2E ------WBMA1F7SJOO6FKDF7QIWA1G4Z1SPBW Content-Type: application/pgp-signature; name="signature.asc" Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQE9BAABCgAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJYjOMM AAoJEGOZARBE6K+yz4MH/iL2PdngP5Z2aKGi6BbafcnlMqGfGGcNiXQAsth7skmp vDW7qj2YsCYpDbv9YzvcUAfRBFzr1y/pgPfaH++vtoe6E0JXKPL3uq9897ztK9oS HQsB0wnY3cz8YndOPYTuGq3RyUV4F80naiPD3uaybSFnwFYdBua/vXiSbMEgRBai KHopVxuqmYBWo8XPaot3Ezo4zNooyXWD/1EcewrwMU2VCw6XPmYhoDMcaSaZNQGk c9fvTazrWwQce2zJ81ouMaO6Z3tqxUYnKg2vB/iWZVXVU6fc9ENOCjajfHy/Gdnq I88tg+uinWH2mh1AkGwDEmPg0l2y4B2aSIPF7o6kwvY= =2eLt -----END PGP SIGNATURE----- ------WBMA1F7SJOO6FKDF7QIWA1G4Z1SPBW--