From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id B25A4C0893 for ; Tue, 22 Dec 2020 01:11:46 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id 9E3F8870AF for ; Tue, 22 Dec 2020 01:11:46 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5RhkkiPKdJ1 for ; Tue, 22 Dec 2020 01:11:44 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.wpsoftware.net (wpsoftware.net [96.53.77.134]) by hemlock.osuosl.org (Postfix) with ESMTP id 9F883870A8 for ; Tue, 22 Dec 2020 01:11:44 +0000 (UTC) Received: from boulet (boulot.lan [192.168.0.193]) by mail.wpsoftware.net (Postfix) with ESMTPSA id A377B40193; Tue, 22 Dec 2020 01:11:43 +0000 (UTC) Date: Tue, 22 Dec 2020 01:11:42 +0000 From: Andrew Poelstra To: Pieter Wuille , Bitcoin Protocol Discussion Message-ID: <20201222011142.GF106279@boulet> References: <20201218152720.GW106279@boulet> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="GH3qgo5c4/nsO7bB" Content-Disposition: inline In-Reply-To: Subject: Re: [bitcoin-dev] BIP-0322 (generic signmessage) improvements X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2020 01:11:46 -0000 --GH3qgo5c4/nsO7bB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 22, 2020 at 12:22:37AM +0000, Pieter Wuille via bitcoin-dev wro= te: >=20 > Re-reading your proposed text, I'm wondering if the "consensus-only valid= ation" extension is intended to replace the inconclusive-due-to-consensus-a= nd-standardness-differ state. If so, I don't think it does, and regardless = it doesn't seem very useful. >=20 > What I'm suggestion could be specified this way: > * If validator understands the script: > * If signature is consensus valid (as far as the validator knows): > * If signature is not known to trigger standardness rules intended fo= r future extension (well-defined set of rules listed in BIP, and revisable)= : return valid > * Otherwise: return inconclusive > * Otherwise: return invalid > * Otherwise: return inconclusive >=20 > Or in other words: every signature has a well-defined result (valid, inva= lid, inconclusive) + validators may choose to report inconclusive for anyth= ing they don't understand. >=20 > This has the property that as long as new consensus rules only change thi= ngs that were covered under for-future-extension standardness rules, no two= validators will ever claim valid and invalid for the same signature. Only = valid+inconclusive or invalid+inconclusive. > I like it! My thinking regarding standardness vs consensus rules was essentially that I wanted to enforce the included standardness rules for anti-malleability reasons, i.e. the hope that for "normal scripts" we would get strong signat= ures, which may be important for anti-DoS reasons. (What I mean by this is that if you can easily create mutations of signatures, it may confuse software in similar ways to the Gox-era malleability attacks on wallet software of the time.) But conversely, it is hard to enforce these rules as an implementor, because libbitcoinconsensus does not expose them. So allowing both forms of validation, to me, was an attempt to encourage adoption rather than anything principled. I didn't even consider the idea that validators should be able to signal "t= his signature appears to use future consensus rules", although I should have be= en clued in by your "upgradeable rules" language that this was your goal. Now = that you say this, it's obvious that this is desireable, and also obvious that u= sing the "inconclusive" state is an elegant way to achieve this. I also agree that "confirming validators should never disagree on valid vs invalid" is a good design goal and we should make that explicit. I'll add a commit to my PR at https://github.com/bitcoin/bips/pull/1048 whi= ch adds these thoughts. --=20 Andrew Poelstra Director of Research, Blockstream Email: apoelstra at wpsoftware.net Web: https://www.wpsoftware.net/andrew The sun is always shining in space -Justin Lewis-Webster --GH3qgo5c4/nsO7bB Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEkPnKPD7Je+ki35VexYjWPOQbl8EFAl/hR8cACgkQxYjWPOQb l8HnLgf/ePpF2V0nD9lOVVZZWWnVJ8gFIc19qZHqOkHtBFNR+Qtd1VyuVY4Dog7C dsLUal/JMr3nX4D88D3rRtg6n9xRPOn1MIzUjKp4Lr7t9k47nvQyTzVU0yNUtIk3 m6Lgw67sugt5oG+PXUImn3vVmc+rSdGNXMqBPV8bVuTXqwbfIXXochHNV7yPVx5e lABlrMNEKko9CRyzbtLAVa2/dPlNOF31wS3/s0u6LPoHRzwTst548BW9IAmNur6i h2nBvEQ+2dmmhvvz4Jtbf6fCSlwrSa2rwGkEjztFGj1kRuiAtHrrPwE6AcilgCo2 VVXj4escwnMeQELkWBJUsO/d6sAYcA== =gxdo -----END PGP SIGNATURE----- --GH3qgo5c4/nsO7bB--