SLIP10 v2?

[skaht]

Is there a group requesting to extend SLIP10 yet to support/extend more immediate curves such as RISTRETTO that solves the cofactor = 8 issue that limits ed25519 SLIP10 functionality, specifically no ed25519 Public parent key → public child key ?

For the longer term, SafeCurves indicates and OpenPGP v5 and GPG No Longer to Support RSA indicates a need to extend extended keys. Hashing functionality greater than 512 bits is needed, and should be standardized.

[prusnak]

Is there a group requesting to extend SLIP10 yet to support/extend more immediate curves such as RISTRETTO that solves the cofactor = 8 issue that limits ed25519 SLIP10 functionality, specifically no ed25519 Public parent key → public child key ?

I don't know of any group request.

[yurisich]

If there's interest in "extending extended keys", I would appreciate including some guidance for creating a standardized format for any key operations (metadata) produced as a result of intermediate hashing, etc. I think something like this would be better off as a separate SLIP, personally.

For example, slip-0010 says:

To avoid invalid master keys, the algorithm is retried with the intermediate hash as new seed if the key is invalid.

As more curves are added, I can see things like this occurring more frequently. Similar to the motivation behind slip-0015, being able to securely store/retrieve/analyze this metadata can aid wallet users who have used "slip-0010/bip32 compatible" derivation strategies which have somehow resulted in lost keys, without having to have access to an exact (buggy) version of software to sweep funds out of it.

[skaht]

Seeing an emerging Web 3.0 related need for BLS12-381 support and possibly ed448 curve extension. Booking marking this page to monitor attention.