Andrew Poelstra [ARCHIVE] on Nostr: 📅 Original date posted:2020-12-23 📝 Original message:On Tue, Dec 22, 2020 at ...
📅 Original date posted:2020-12-23
📝 Original message:On Tue, Dec 22, 2020 at 12:22:37AM +0000, 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'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 protocol.
4. I removed the "to_sign" transaction from the wire serialization, since after 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.)
--
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20201223/858f723b/attachment.sig>;
📝 Original message:On Tue, Dec 22, 2020 at 12:22:37AM +0000, 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'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 protocol.
4. I removed the "to_sign" transaction from the wire serialization, since after 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.)
--
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20201223/858f723b/attachment.sig>;