📅 Original date posted:2020-12-21
📝 Original message:On Sunday, December 20, 2020 9:37 PM, Karl-Johan Alm via bitcoin-dev <bitcoin-dev at 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).
Cheers,
--
Pieter
Pieter Wuille [ARCHIVE] /
npub1tj…jtl6r
2023-06-07 18:27:52
in reply to nevent1q…wjhw
Author Public Key
npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6rPublished at
2023-06-07 18:27:52Event JSON
{
"id": "fe83aebd7b128b03ebb341149877cced784ceaf309bd00c583ebea02b7f51cc3",
"pubkey": "5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6",
"created_at": 1686162472,
"kind": 1,
"tags": [
[
"e",
"e10447dfee8bafa1171ad4dfa089cd3f0a462be97bcbeeb2c3d15ed54e8a353f",
"",
"root"
],
[
"e",
"91d3d2f2698d35c98cdf494b3046a2593e2ac9e43c38263b3d79c1fcbd018c6b",
"",
"reply"
],
[
"p",
"f61d6f5f7a545bba4c32170f8630a5adeb1b2ad9ecf2881dde3988cfe447b801"
]
],
"content": "📅 Original date posted:2020-12-21\n📝 Original message:On Sunday, December 20, 2020 9:37 PM, Karl-Johan Alm via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Thanks a lot for taking the time to brush up the BIP. For what it's\n\u003e worth, I am all for these changes, and I see them as clear\n\u003e improvements all around.\n\u003e\n\u003e IIRC Pieter was the one who originally suggested the two-checks\n\u003e approach (invalid, inconclusive, valid) which is being modified here,\n\u003e so would be good if you chimed in (or not -- which I'll assume means\n\u003e you don't mind).\n\nI 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.\n\nThis 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).\n\nSince 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).\n\nCheers,\n\n--\nPieter",
"sig": "c6d960f6b7bb2836853fd1ce26cb1ee80977d5182a5428d72b3b2e6d51695ba1beb4422732262f397dde91f296c7cfae993e490dfb5936399ca4d504db494694"
}