From mboxrd@z Thu Jan 1 00:00:00 1970 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 C282E13FF for <bitcoin-dev@lists.linuxfoundation.org>; Mon, 28 Sep 2015 15:05:49 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail149095.authsmtp.com (outmail149095.authsmtp.com [62.13.149.95]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id E805D243 for <bitcoin-dev@lists.linuxfoundation.org>; Mon, 28 Sep 2015 15:05:48 +0000 (UTC) Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237]) by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t8SF5lhU038905; Mon, 28 Sep 2015 16:05:47 +0100 (BST) Received: from savin.petertodd.org (75-119-251-161.dsl.teksavvy.com [75.119.251.161]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t8SF5h7X080267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 28 Sep 2015 16:05:46 +0100 (BST) Date: Mon, 28 Sep 2015 11:05:43 -0400 From: Peter Todd <pete@petertodd.org> To: Mike Hearn <hearn@vinumeris.com> Message-ID: <20150928150543.GB28939@savin.petertodd.org> References: <20150927185031.GA20599@savin.petertodd.org> <CA+w+GKRCVr-9TVk66utp7xLRgTxNpxYoj3XQE-6y_N8JS6eO6Q@mail.gmail.com> <20150928132127.GA4829@savin.petertodd.org> <CA+w+GKTCZDNVJ-XEmsCAWGXUV3xOzVYmqMQYm0x+ihyYWQN0Gg@mail.gmail.com> <20150928142953.GC21815@savin.petertodd.org> <CA+w+GKTUz2eVJOpixSebWiQ59ovoELNhsZWSsbLHXWqk2eCn0A@mail.gmail.com> <20150928144318.GA28939@savin.petertodd.org> <CA+w+GKSuO2v+92hJUckcYdHcjkPVNg4opDL98yygGp-gqB9Jtg@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wzJLGUyc3ArbnUjN" Content-Disposition: inline In-Reply-To: <CA+w+GKSuO2v+92hJUckcYdHcjkPVNg4opDL98yygGp-gqB9Jtg@mail.gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 65ab6dc8-65f2-11e5-9f76-002590a135d3 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdAoUC1AEAgsB AmMbWlJeUFh7XWU7 bA9PbARUfEhLXhtr VklWR1pVCwQmRRRi cBtGVXFyfwVEfnk+ bEVrWj5dWRUocxIu SlNSEDsEeGZhPWUC WRZfcR5UcAFPdx8U a1N6AHBDAzANdhEy HhM4ODE3eDlSNhEd ZgwRYklaTUsTGjkt DzojJWtyVWYlag4Q CzsNCWI9OWsvH38T H2poMf9/ X-Authentic-SMTP: 61633532353630.1024:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 75.119.251.161/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] Let's deploy BIP65 CHECKLOCKTIMEVERIFY! 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 Sep 2015 15:05:49 -0000 --wzJLGUyc3ArbnUjN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 28, 2015 at 04:51:22PM +0200, Mike Hearn wrote: > > > > Ok, so again, if that's your security criteria, what's the issue > > with soft-forks? >=20 >=20 > Please read my article as it's all explained there. I have read your article. In fact we reviewed it at a NY BitDevs meetup that I attended. > But to reiterate: the risk is that miners will build invalid blocks on top > of the best work chain, instead of an ignored lower work side chain. This > opens users to payment fraud. With a hard fork, all the blocks by miners > that aren't checking all the rules anymore get neatly collected together = on > a side chain after the split, and wallets all know how to ignore that cha= in. Can you explain exactly how you think wallets will "know" how to ignore the invalid chain? With an advertised soft-fork, e.g. the IsSuperMajority() mechanism, ignoring the invalid chain is easy: use nVersion to detect invalid blocks when you know what soft-forks are coming up, and if presented with an unknown - but advertised - soft-fork at minimum loudly warn the user. In the case of a hard-fork identical logic can be used. (BIP101 being an example of a hard-fork triggered in a way that can be detected by SPV clients, both explicitly (BIP101 specific) and implicitly (general unknown block nVersion warnings)) > Yes, you made OP_NOPs be non-standard. So out of the box, miners won't > create invalid blocks, as long as they're running Core past that version. > But this makes the IsStandard function very much like a part of the > consensus rules, as bypassing it can result in invalid blocks being > created. How so? Miners can always choose to create invalid blocks, thus attacking SPV wallets; my statement with regard to pull-req #5000 comes =66rom a risk-based approach, knowing that every invalid block is expensive and the new concern created by a soft-fork is whether or not miners will create them accidentally; miners can always create invalid blocks delibrately. > Miners have always understood that they can modify this function, > or even bypass it entirely, without affecting the validity of their block= s. > And some miners do exactly that. That's incorrect: Miners bypassing IsStandard() risk creating invalid blocks in the event of a soft-fork. Equally, we design soft-forks to take advantage of this. > So I'll repeat the question that I posed before - given that there are > clear, explicit downsides, what is the purpose of doing things this way? > Where is the gain for ordinary Bitcoin users? We seem to be in strong disagreement about which option has "clear, explicit downsides" --=20 'peter'[:-1]@petertodd.org 0000000000000000006f2abe95e361b73289e4a79ba3124801896f6b7dc8d977 --wzJLGUyc3ArbnUjN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJWCVdDXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAwZDZjYTE2YjNiNTRjMWQ5ODI0NGZkYmZmYzg1ZjJhZjAy MDY4MjlkMDc3OGEyNWEvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkftiIggAnkcSgmIn5hsltGI0lmPeiylp ZhMjUsXl40ZkOYq5/KIpVw9JBO6zUvG+C7dsd6TbOdcCfVyMaXhbBa0J41XiipBM PU4FdlpNhMJuqHcu9i4wNdljnN0zBpw0QO1n1vSZuY6w5dGze/z5OvSxbAEW1Klx 3U7U+HV5cbcpZRPp9QEgswP5Ocstryxatw9pqz7NrOZNI8Af4qSm7IactigO4qhw pq3c4irSk9zAsDDZ7sMZvlyIeyEUcy3EAdYCqyU6cHr27TcoXG4Sy74CPNWGw5V9 xpCH5ZiO6AswdD1f/SCHvxAS3FTKTYDY8d3qZh3nnjJ9jWN0hIg6rDM6xMdo2g== =6i5f -----END PGP SIGNATURE----- --wzJLGUyc3ArbnUjN--