Documentation omission: compactSize encodings must be canonical #8721

The documentation of a compactSize field in the Bitcoin Developer Reference describes four possible encodings based on length. The ranges of integers expressible in each encoding overlap. Therefore it is possible in principle to represent a compactSize with a non-canonical encoding that uses more than the minimum number of bytes.

The actual implementation of ReadCompactSize excludes this possibility. This is also tested. However, it is not documented. Since it affects consensus, it should be documented.

(Ref: https://github.com/zcash/zcash/issues/842 , which is a potential security bug that the Zcash fork of Bitcoin would have had if canonicity were not enforced.)

I believe back when the documentation was written, we did not enforce compact size, however we did re-serialize blocks (and I believe transactions) when using compactsize for consensus-critical things (eg serialized size checks). For simplicity and to make correctness more obvious, we now enforce the minimal encoding, but I not believe "it affects consensus" aside from being a rule on the p2p network. Still, this should be filed at https://github.com/bitcoin-dot-org/bitcoin.org/ as that is where the documentation in question lives.

I'll refile it and continue the discussion there.