SLIP-0010: Clarification w.r.t ed25519 public keys

[hanssv]

The test vectors have 33-byte public keys for ed25519 (first byte is always zero?). This seems very ad-hoc (public keys for ed25519 are normally 32-bytes) - is it documented/specified somewhere?

(Note: BIP32 doesn't help, rather the opposite since: ser_P(P): serializes the coordinate pair P = (x,y) as a byte sequence using SEC1's compressed form: (0x02 or 0x03) || ser256(x), where the header byte depends on the parity of the omitted y coordinate. - is just plain wrong for ed25519?!)

So am I missing some relevant wording somewhere? The place where this matters is the fingerprint since it seems to be computed over a 33-byte public key)

[prusnak]

Yes, it is ad-hoc.
We use the first byte 0x00 to indicate that the rest is an ed25519 key, not an ecdsa key (which is indicated by first byte 0x02 or 0x03).

[skaht]

Appears that ed25519 public keys are by default always compressed and RFC Section 13.3 indicates the canonical prefix for ed25519 and cv25519 public keys are 0x40, the "@" character. Also see https://www.ietf.org/archive/id/draft-ietf-openpgp-rfc4880bis-10.html#section-appendix.b.

[hanssv]

I never made it past the EdDSA RFC where it is just 32 bytes

[steed717]

@prusnak: so, based on your comments below, how should the ed25510 public key be serialized to follow and be compatible with BIP32? Should the 0x00 be kept to make the public key 33 bytes and then base58 out regardless of the parity (the ed25519 public key in 32 bytes should be compressed format already)? And when you say ad-hoc, do you mean the lead 0x00 padding may change to some other stuff later?
(refer: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#serialization-format)

Yes, it is ad-hoc.
We use the first byte 0x00 to indicate that the rest is an ed25519 key, not an ecdsa key
(which is indicated by first byte 0x02 or 0x03).

[prusnak]

Should the 0x00 be kept to make the public key 33 bytes

Yes

do you mean the lead 0x00 padding may change to some other stuff later?

No

[steed717]

Should the 0x00 be kept to make the public key 33 bytes

Yes

do you mean the lead 0x00 padding may change to some other stuff later?

No
Thank you for the quick reply. Just double confirm with you that when serialization the public edd25519 key, e.g. base58, the default 32 bytes compressed format is used as it + leading 0x00, same for private ed25519 key, it uses leading 0x00 too?