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 DAECA2C for ; Sat, 13 May 2017 12:49:01 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail148106.authsmtp.co.uk (outmail148106.authsmtp.co.uk [62.13.148.106]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 86610F0 for ; Sat, 13 May 2017 12:49:00 +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 v4DCmsFL075243; Sat, 13 May 2017 13:48:54 +0100 (BST) 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 v4DCmqdH005571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 May 2017 13:48:53 +0100 (BST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by petertodd.org (Postfix) with ESMTPSA id D7E3D4008E; Sat, 13 May 2017 12:48:51 +0000 (UTC) Received: by localhost (Postfix, from userid 1000) id E897720486; Sat, 13 May 2017 08:48:48 -0400 (EDT) Date: Sat, 13 May 2017 08:48:48 -0400 From: Peter Todd To: Luke Dashjr Message-ID: <20170513124848.GC8884@fedora-23-dvm> References: <201705121922.57445.luke@dashjr.org> <20170512222214.GA4462@fedora-23-dvm> <201705130049.33798.luke@dashjr.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="GZVR6ND4mMseVXL/" Content-Disposition: inline In-Reply-To: <201705130049.33798.luke@dashjr.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Server-Quench: 8551e5ae-37da-11e7-829f-00151795d556 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdwEUFVQNAgsB AmEbWldeVFV7XGA7 bghPaBtcak9QXgdq T0pMXVMcUgEcckFA UmYeUhx3cAQIeXx2 Y0AsVnVeXRF/JBNg QUkARHAHZDJndWgd WRZFdwNVdQJNdxoR b1V5GhFYa3VsNCMk FAgyOXU9MCtqYA50 elNFB1YVSkVDBT8z QRkGVTgpE0ofTCg2 Iho6YkAdFQ4NIg08 PFY6Mf9/ 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 Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] BIP: Block signal enforcement via tx fees 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, 13 May 2017 12:49:02 -0000 --GZVR6ND4mMseVXL/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, May 13, 2017 at 12:49:33AM +0000, Luke Dashjr wrote: > On Friday 12 May 2017 10:22:14 PM Peter Todd wrote: > > nVersion signaling is already technically unenforceable, in the sense t= hat > > we don't have good ways of ensuring miners actually adopt the rules > > they're claiming to signal. Equally, it's users who ultimately adopt > > rules, not miners, and attempting to pay miners to signal certain bits > > will further confuse this point. >=20 > This BIP doesn't change that. Enforcement remains primarily by users. I'm not arguing that it changes that; I'm arguing that it further confuses = the situation. > > Quite likely the outcome of users trying to anonymously pay anonymous > > miners to signal certain bits will be the complete breakdown of the > > honesty of the nVersion signalling system, currently enforced only by > > "gentlemans agreement". >=20 > You assume users will pay for signalling of softforks prematurely. So lon= g as=20 > it waits until deployment of the softfork is widespread, this risk is min= imal.=20 > At worst, it creates risks similar to a UASF. So long as UASF is the=20 > alternative, this way seems strictly better. I think you're assuming that the users paying for soft-fork signalling will represent an economic majority; that's not necessarily the case. For example, if miners decide there's no downside to false signalling, they= may take the extra fees provided by 1% of the users paying to signal a fork, wh= ile the other 99% don't participate, resulting in a situation where we have blo= cks violating the nVersion protocol, and an unknown % of that 99% rejecting tho= se blocks. At best that'd be no worse than a UASF, and at wost you're wrecked = the validity of the nVersion "gentlemans agreement" > > Also, as an aside, this "specification" again shows the inadequacy and > > unreadability of English language specifications. I'd strongly suggest = you > > delete it and instead mark the "reference implementation" as the > > specification. >=20 > How so? Just read it: you have ten separate lines of dense English text describing something that could have been specified instead by ten lines of much more formally defined C++. In particular, note how many of those lines of English text refer to C++ code anyway, like the sentence "minimal-length 40-bit CScriptNum" I don't want to have to learn another language - formally defined English t= hat still fails to be formally defined - just to read Bitcoin's specification. --=20 https://petertodd.org 'peter'[:-1]@petertodd.org --GZVR6ND4mMseVXL/ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZFwCvAAoJECSBQD2l8JH7BvoH/3FyKbT2CB4HCYFMtJc4uaOm IfSgU+EKGJYs37nnQyaovBCUeTory/1rB6hfy0T4e9aOzLuqdtsgP+qIPRrvJ0xy q+/rIrSM7l2w0hCE56hz0QW7OgW6og5vFq3U5GNONXEMBD2uwFSE26BVB5h2yU41 V4WVEYqsELnoYEO1ZB32Hsk+nxiM4GZ2IXObnxnNG70eM/YBdMgIszjzMwMvoP+m JHwSJpegCFl1rQCWOsL94L7BkaZ/9p2YWLwirtVKLRzUAFS0MHDtoRErmuGETZ0X ghdBBnUR5kGimzLDKG1H0lsYEwI8Y9ToDmrnd6eB+jnm1AdsPocSIinhj2HI+BQ= =/J+C -----END PGP SIGNATURE----- --GZVR6ND4mMseVXL/--