Skip to content

Conversation

@theuni
Copy link
Member

@theuni theuni commented Nov 5, 2014

Cleaned up version of #5188

Attempt to codify the possible error statuses associated with script
validation. The second commit (move-only) moves the other flags into the newly
created script/types.h as part of the upcoming external interface.

Logging has also been removed in order to drop the dependency on util.h. It can
be re-added to bitcoind as-needed. This makes script verification finally free
of application state and boost!

@sipa
Copy link
Member

sipa commented Nov 5, 2014

@theuni I was actually thinking not to expose the script verification flags externally, as they are implementation and policy specific, but instead have the interface define its own flags, which get translated into internal ones.

@theuni
Copy link
Member Author

theuni commented Nov 5, 2014

I'll defer to you on that. I can nuke the top commit and save that for a separate discussion.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These two are also under BIP62 (they're also used for standardness checks outside of BIP62, but that shouldn't matter for a consensus lib).

@gmaxwell
Copy link
Contributor

gmaxwell commented Nov 5, 2014

With respect to the concern that callers might use the error code to decide pass/fail instead of the actual return. Why not set the error value to the unknown error at entry, so long as an error pointer is provided at all?

@theuni
Copy link
Member Author

theuni commented Nov 6, 2014

Updated for @sipa's and @gmaxwell's comments.

@theuni theuni mentioned this pull request Nov 7, 2014
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: can you add the error messages that you remove here as comment? ie

- if (vchPubKey.size() < 33)
+ if (vchPubKey.size() < 33) // Non-canonical public key: too short
- return error("Non-canonical public key: too short");
+ return false;

We do lose some troubleshooting information here, as the error mechanism provides no way to signal warnings/details of script interpretation. But I don't see an alternative either. Maybe in the future it would be useful to add a way to get a detailed trace of execution.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I started to add a bitmask for more detailed info in the case of ERR_EVAL_VALSE or ERR_VERIFY_*, but that ended up looking a little over-engineered and error-prone. If you think it's worth it, i can re-add that.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's not necessary for this pull

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But please do add the comments as suggested, so that the cases are documented and if later on we have a way to return details execution status, we can return it.

@laanwj
Copy link
Member

laanwj commented Nov 7, 2014

Looks good to me, utACK (will test)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Currently this function is unused! Shouldn't we call this function where we use EvalScript/VerifyScript, and log the message?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@laanwj I didn't want to hook it up in each place, since it could be potentially much noisier than the old logging. To be close to on-par with current behavior, we could check for something like SCRIPT_ERR_SIG_DER || SCRIPT_ERR_SIG_HASHTYPE || SCRIPT_ERR_SIG_HIGH_S. Those are pretty arbitrary though.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it's pretty arbitrary. But it's also strange to have a function that is called from nowhere, not even from the unit tests. But I'm fine with doing that in a later pull, and regarding this as preparation.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@laanwj Yes, I'd prefer to address the logging in a later pull, as I assumed that would lead to some bikeshedding. Though I agree that it wouldn't make sense to push this without using it anywhere, so I've updated the tests to check the values.

@theuni
Copy link
Member Author

theuni commented Nov 11, 2014

@laanwj Sorry, I missed your comment (about comments) the first time around. re-added those and rebased on master.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isnt this unknown opcode?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, thanks for catching that!

@TheBlueMatt
Copy link
Contributor

ACK commithash 4eefa373ae4866a1ad25cea3615270f58693e6a7 (+/- the incorrect error message on unknown opcode): http://bitcoin.ninja/TheBlueMatt-5212.txt

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry to nit, but indentation is wrong here (and in some other places where comments are added)

@sipa
Copy link
Member

sipa commented Nov 14, 2014

@theuni to get back to an earlier comment I made: if #5247 would be merged, non-standard public key encoding do result in script failure immediately, so IsCompressedOrUncompressedPublicKey could set a status code etc, like you did earlier.

@laanwj
Copy link
Member

laanwj commented Nov 14, 2014

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

ACK ddadf2d1ecc0d646ae83b06f275c15a5a7704573 after squash
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCgAGBQJUZeZIAAoJEHSBCwEjRsmmDvEH/1Ugi0b3iy70QKEw3OBs+yc1
uOvlkBuNVX+UM6alY90jJp5WZRNLnoOKv/1CZW8kD6jPZsb4fHJG9jE3xhvNY5sY
6M0T4LTZzhqFHqC2ob1sXpHkztfQ/+klmJh1rrPCgDb2KtrIcHJT2ZNHl59WZQ1S
tCHAQz23COk7O9uACRhqKB3oCmmxxnI/IzmEOncaMHR2at0DL9/Z90FOWD65OoLM
bl4SIx3MEBXkgvgAB/41eQ1oWTVuxTl0FexhgUsNQWgHzpNxFOoHSraDBfED4DVy
ZOOVmyS6o0GaCbVy/xlrdbUaM5Gm/MsYPZV65BZesIGa2lJLgTM/Jha4uD3ECyw=
=+m+q
-----END PGP SIGNATURE-----

@theuni
Copy link
Member Author

theuni commented Nov 14, 2014

@sipa Ok, thanks. If/when that happens, I'll follow-up with the more detailed values.

@theuni
Copy link
Member Author

theuni commented Nov 14, 2014

Squashed. This is code-identical to the last push except for the comments white-space nit fix.

…ve logging

Attempt to codify the possible error statuses associated with script
validation. script/types.h has been created with the expectation that it will
be part of the public lib interface. The other flag enums will be moved here in
a future commit.

Logging has also been removed in order to drop the dependency on core.h. It can
be re-added to bitcoind as-needed. This makes script verification finally free
of application state and boost!
@sipa
Copy link
Member

sipa commented Nov 17, 2014

utACK

@laanwj laanwj merged commit 219a147 into bitcoin:master Nov 17, 2014
laanwj added a commit that referenced this pull request Nov 17, 2014
219a147 script: check ScriptError values in script tests (Cory Fields)
ab9edbd script: create sane error return codes for script validation and remove logging (Cory Fields)
@bitcoin bitcoin locked as resolved and limited conversation to collaborators Sep 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants