Please don't mark this as trivial (it's changing the code being compiled), but otherwise obvious ACK.

Please don't mark this as trivial (it's changing the code being compiled), but otherwise obvious ACK.

You could argue that it doesn't, actually, but I'll keep that in mind.

You could argue that it doesn't, actually, but I'll keep that in mind.

One way to find out for sure: compare executables with https://github.com/bitcoin-core/bitcoin-maintainer-tools/blob/master/build-for-compare.py.
(though I don't think this argument is worth it, utACK anyhow, please update the commit message too)

utACK c1e5e27e7a612703f7351f8fc9ce47be669d93ca

Removed "[trivial]" from commit message.

utACK 3f09e03.

Tend to NACK here, since a related pull was just merged: #10574 and I fail to see why this change wasn't included there. I'd rather avoid another upcoming wave of commits with little value compared to the review it has to go through.

I am fine if you improve the travis check (#11878) instead.

In case my NACK is invalid, binary diff:

<   3554a6:	mov    $0x6b,%edx
---
>   3554a6:	mov    $0x6a,%edx

utACK 3f09e03

@MarcoFalke I don't see why the other merge is related, and I don't think this commit has little value. Removing redundant/unused includes is quite beneficial in many cases. And one-liners are trivial to review.

The duplicate includes PR you pointed to seems slightly unrelated. This isn't a duplicate include, this is an unused include. Nowhere in the hash.cpp code does it use anything from pubkey.h. It may be possible to use static analysers to detect that sort of thing, but it smells like something that would give false positives occasionally.

@kallewoof Jup, you are right.