Date: Wed, 23 Dec 2020 15:55: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: <20201223155542.GN106279@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="YqYfhc9BoyB5fAQz"
Content-Disposition: inline
In-Reply-To: <pa8YeCM--QSIGM9vegsiOzaxoLyXm55KTGQBZJk2Waw6blIz3l_RxY-rgKRQ40LmJupOmL-orWwfY7tVpDVboXd4BCCpZZEbC30l8HDum2k=@wuille.net>
Subject: Re: [bitcoin-dev] BIP-0322 (generic signmessage) improvements
Precedence: list


--YqYfhc9BoyB5fAQz
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've updated my PR at https://github.com/bitcoin/bips/pull/1048

Differences:

1. I compacted all the validation states into three: valid at time/age T/S,=
 invalid,
   and inconclusive.

2. "Inconclusive" means either an "upgradeable rule" failed, e.g. use of a =
NOP or a
   bad network version, or the validator just didn't understand the scripts.

3. I removed the "Extensions" sections now everything is in the main protoc=
ol.

4. I removed the "to_sign" transaction from the wire serialization, since a=
fter all
   this, it can always be inferred from the message and address. (This does=
 mean,
   however, that there is no way to sign for scriptPubKeys that don't have =
addresses,
   e.g. bare public keys or multisigs. I don't think it's worth complicated=
 the
   protocol for such obscure things.)

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


--YqYfhc9BoyB5fAQz
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEkPnKPD7Je+ki35VexYjWPOQbl8EFAl/jaHwACgkQxYjWPOQb
l8HpGQf/b97fbDKSwU8y0VVXe4UQOx/Eg7+6uKZLzWD3FldN0vBxmrPmYWrAW/rZ
et7+nws6TA8qe4S/FQRKOJ7uKfUce87VfAjeB1usnjk1khxcCGpeYzSywlAO7NyG
mNcz+vBOoOHhTcN7o6oLdxM4mowLsX0nbYeC8E4lHaqv2OFhQ85roE2tNLCJM25G
ONZctQDsdGXm6QFVGwJzGgifAK/wMwn/1YTSfqWpWwYBxZojdCUrTJX6Op7Pxb51
yV0ynXgzLU9HL+0h+mFS8BRfoIcTZ/33Pvp2HRTfszVP21vZ1bb8ufkQ/y8DfRYM
zMoiPgFKxHuKVnwh5Bsgwlp4uXqnqQ==
=MItC
-----END PGP SIGNATURE-----

--YqYfhc9BoyB5fAQz--