Date: Tue, 22 Dec 2020 01:11:42 +0000
From: Andrew Poelstra <apoelstra@wpsoftware.net>
To: Pieter Wuille <bitcoin-dev@wuille.net>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20201222011142.GF106279@boulet>
References: <20201218152720.GW106279@boulet>
 <CALJw2w4bFp8qcxNzz7hn_ZeGG8WWTPu-mRv6A4cPt66EHimyeg@mail.gmail.com>
 <Xpjf4qIbUPHa_K-yS1GRlsG4rVXBR9OHgzsxjgABhw0hg7jPFn4l4wwgVH_1iRVR5jFDK2cUb0qsbA1FQKiQZRTFPh77MGibgaVUaVbB_Ng=@wuille.net>
 <pa8YeCM--QSIGM9vegsiOzaxoLyXm55KTGQBZJk2Waw6blIz3l_RxY-rgKRQ40LmJupOmL-orWwfY7tVpDVboXd4BCCpZZEbC30l8HDum2k=@wuille.net>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature"; boundary="GH3qgo5c4/nsO7bB"
Content-Disposition: inline
In-Reply-To: <pa8YeCM--QSIGM9vegsiOzaxoLyXm55KTGQBZJk2Waw6blIz3l_RxY-rgKRQ40LmJupOmL-orWwfY7tVpDVboXd4BCCpZZEbC30l8HDum2k=@wuille.net>
Subject: Re: [bitcoin-dev] BIP-0322 (generic signmessage) improvements
Precedence: list


--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--