Fix InputWeightPrediction::P2WPKH_MAX constant DER sig length

[conduition]

The P2WPKH_MAX constant assumed DER signatures in the witness have a max length of 73. In practice, their maximum length is 72, because BIP62 forbids nodes from relaying transactions which contain non-canonical ECDSA signatures (i.e. TX sigs must have an $s$ value of less than $\frac{n}{2}$).

This means $s$ is never encoded with a leading zero byte, and the signature as a whole never exceeds 72 bytes in total encoded length. The ground_p2wpkh function was already correct; only the constant needed to be corrected.

Technically 73 bytes is the upper limit for signatures, as nothing forbids miners from including such non-standard transaction signatures in blocks, but for the purposes of fee estimation and input weight prediction, 72 is the number which 99.9% of implementations should use as their ceiling. We already use it as the ceiling for the ground_p2wpkh function - ground_p2wpkh(0) returns a prediction which uses a witness signature of length 72.

Reference:

• https://bitcoin.stackexchange.com/questions/77191/what-is-the-maximum-size-of-a-der-encoded-ecdsa-signature
• https://bitcoin.stackexchange.com/questions/106435/are-high-s-ecdsa-signatures-forbidden-in-segwit-witnesses
• https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki

To enable testing, I added a weight() method to InputWeightPrediction and made it public but i'm not sure whether it has a use-case. Let me know if I should make it private instead.

[tcharding]

ACK f41ebc2

[apoelstra]

ACK f41ebc2

[murchandamus]

Concept ACK:
Note that BIP62 was withdrawn, but as you describe high-s signatures are non-standard. This was achieved per BIP66, so using 72 bytes as the upper bound for serialized ECDSA signatures leads to the correct outcome during transaction building.

[Kixunil]

Shit, I only noticed this now. I kinda worry that people might misuse this but the documentation is pretty good so maybe not a big deal.