2021.06.15 22:01:30 (1404891836645208066) from Daniel J. Bernstein, replying to "Steven Galbraith (@EllipticKiwi)" (1404377032725651464):
Yes, the suggestion in Section 5.3 of https://cr.yp.to/papers.html#multischnorr ends up setting bit 255 instead. The hashing is under very different constraints: doubling the output size simplifies parts of the design, helps protect implementations (as we saw with Minerva), and doesn't cost much.
2021.06.15 22:11:57 (1404894466469625856) from Daniel J. Bernstein:
Part of the design process is predicting software incentives and turning those into helping, rather than hurting, security. Look at, e.g., https://mailarchive.ietf.org/arch/msg/cfrg/8z3ZcujGRxFSGEBI-uE7C1tjw4c/ explaining in 2014 how 512-bit nonces protect simple non-reducing implementations against nonce timing attacks.
2021.06.14 01:22:02 (1404217529363402759) from "Steven Galbraith (@EllipticKiwi)":
I dont mind the leading 1. It's the zero LSB that seems unnecessary
2021.06.14 01:46:07 (1404223588123648004) from Daniel J. Bernstein, replying to "Steven Galbraith (@EllipticKiwi)" (1404217529363402759):
Pohlig-Hellman immediately reveals the bottom 3 bits, so setting them to be nonzero wouldn't gain security, while zero gives slight simplifications+speedups in optimized software. The multi-user security questions you mention are tied to the top bits, not the bottom bits.
2021.06.14 11:50:48 (1404375760874270723) from "Steven Galbraith (@EllipticKiwi)":
I could have been more precise in my comments. Fixing a leading bit is ok. But want distribution to be close to uniform. Since p \approx 2^{255} and #E \approx p this is easy. But your choice in EdDSA to use bit 2^{254} and 3 MSB=0, means only 2^{251} possible.
2021.06.14 11:55:51 (1404377032725651464) from "Steven Galbraith (@EllipticKiwi)", replying to "Steven Galbraith (@EllipticKiwi)" (1404375760874270723):
If you'd set bit 255 instead, or not zeroed the last 3 bits, then all would be good. It's interesting that you took a much more conservative approach to the hashing/de-randomization (I would not have gone as far as 512 bit hashing).