Re: [bitcoin-dev] BIP-0322 (generic signmessage) improvements
On Tue, Dec 22, 2020 at 12:22:37AM +, Pieter Wuille via bitcoin-dev wrote: > > Re-reading your proposed text, I'm wondering if the "consensus-only > validation" extension is intended to replace the > inconclusive-due-to-consensus-and-standardness-differ state. If so, I don't > think it does, and regardless it doesn't seem very useful. > > 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 for > future extension (well-defined set of rules listed in BIP, and revisable): > return valid > * Otherwise: return inconclusive > * Otherwise: return invalid > * Otherwise: return inconclusive > > Or in other words: every signature has a well-defined result (valid, invalid, > inconclusive) + validators may choose to report inconclusive for anything > they don't understand. > > This has the property that as long as new consensus rules only change things > 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 signatures, 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 "this signature appears to use future consensus rules", although I should have been 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 using 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 which adds these thoughts. -- 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 signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP-0322 (generic signmessage) improvements
On Monday, December 21, 2020 2:57 PM, Pieter Wuille via bitcoin-dev wrote: > On Sunday, December 20, 2020 9:37 PM, Karl-Johan Alm via bitcoin-dev > bitcoin-dev@lists.linuxfoundation.org wrote: > > > Thanks a lot for taking the time to brush up the BIP. For what it's > > worth, I am all for these changes, and I see them as clear > > improvements all around. > > IIRC Pieter was the one who originally suggested the two-checks > > approach (invalid, inconclusive, valid) which is being modified here, > > so would be good if you chimed in (or not -- which I'll assume means > > you don't mind). > > I agree with the idea of permitting incomplete validators to return > inconclusive as well. That doesn't really reduce the functionality (given > that "inconclusive" was already a potential result), and it obviously makes > it much more accessible to a variety of software. > > This suggestion breaks the original use of inconclusive though: the ability > to detect that future features are used in the signature. The idea was to use > divergence between "consensus valid" and "standardness valid" as a proxy for > future extensions to be detected (e.g. OP_NOPn, future witness versions, > ...). I think it's undesirable that these things now become unconditionally > invalid (until the BIP is updated, but once that happens old validators will > give a different result than new ones). > > Since the BIP no longer relies on a nebulous concept of standardness, and > instead specifically defines which standardness features are to be > considered, this seems easy to fix: whenever validation fails due to any of > those, require reporting inconclusive instead of invalid (unless of course > something actually invalid also happens). In practice I guess you'd implement > that (in capable validators) by still doing validation twice, once with all > features enabled that distinguish between valid/invalid, and if valid, again > but now with the features enabled that distinguish between valid and (invalid > or inconclusive). Re-reading your proposed text, I'm wondering if the "consensus-only validation" extension is intended to replace the inconclusive-due-to-consensus-and-standardness-differ state. If so, I don't think it does, and regardless it doesn't seem very useful. 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 for future extension (well-defined set of rules listed in BIP, and revisable): return valid * Otherwise: return inconclusive * Otherwise: return invalid * Otherwise: return inconclusive Or in other words: every signature has a well-defined result (valid, invalid, inconclusive) + validators may choose to report inconclusive for anything they don't understand. This has the property that as long as new consensus rules only change things 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. Cheers, -- Pieter ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP-0322 (generic signmessage) improvements
On Sunday, December 20, 2020 9:37 PM, Karl-Johan Alm via bitcoin-dev wrote: > Thanks a lot for taking the time to brush up the BIP. For what it's > worth, I am all for these changes, and I see them as clear > improvements all around. > > IIRC Pieter was the one who originally suggested the two-checks > approach (invalid, inconclusive, valid) which is being modified here, > so would be good if you chimed in (or not -- which I'll assume means > you don't mind). I agree with the idea of permitting incomplete validators to return inconclusive as well. That doesn't really reduce the functionality (given that "inconclusive" was already a potential result), and it obviously makes it much more accessible to a variety of software. This suggestion breaks the original use of inconclusive though: the ability to detect that future features are used in the signature. The idea was to use divergence between "consensus valid" and "standardness valid" as a proxy for future extensions to be detected (e.g. OP_NOPn, future witness versions, ...). I think it's undesirable that these things now become unconditionally invalid (until the BIP is updated, but once that happens old validators will give a different result than new ones). Since the BIP no longer relies on a nebulous concept of standardness, and instead specifically defines which standardness features are to be considered, this seems easy to fix: whenever validation fails due to any of those, require reporting inconclusive instead of invalid (unless of course something actually invalid also happens). In practice I guess you'd implement that (in capable validators) by still doing validation twice, once with all features enabled that distinguish between valid/invalid, and if valid, again but now with the features enabled that distinguish between valid and (invalid or inconclusive). Cheers, -- Pieter ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
