1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
|
Return-Path: <apoelstra@wpsoftware.net>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id B25A4C0893
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <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
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol 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: 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--
|
