deriveKeypair and deriveAddress

[pftq]

Is there a way to access these functions? They would be useful to return the address from a secret key and verify a correct address-secret key pair. If not, could they be exposed? Thanks

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/46024319-derivekeypair-and-deriveaddress?utm_campaign=plugin&utm_content=tracker%2F323756&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F323756&utm_medium=issues&utm_source=github).

[sublimator]

https://github.com/ripple/ripple-keypairs

[pftq]

I'm aware of that library. However, it's 2 years old and would be useful to have available in the main ripplelib (especially since the code is already in ripplelib, just not exposed through API). If it's already exposed, let me know, as I might have missed it.

Right now, I'm modifying my copy of ripplelib to do so - it just takes the below 4 lines:

var deriveKeypair = webpack_require(305).deriveKeypair; var deriveAddress = webpack_require(305).deriveAddress; (before // prevent access to non-validated ledger versions)

deriveKeypair: deriveKeypair, deriveAddress: deriveAddress, (before generateAddress: generateAddress, )

[sublimator]

2 years old= pretty stable. Not a moving target

Convenience of it being exported from ripple lib aside ...

[pftq]

Not sure why this is a debate. The code is already in ripplelib - it just needs to be exposed. It would help developers to find everything in one place rather than have to locate an additional library that contains the duplicate code.

[sublimator]

Not sure why you think this is a debate :)

I have no authority to add it to ripple-lib, just saying that you can use ripple-keypairs and get on with life while waiting for someone from ripple that can actually make the changes you want.

[pftq]

Ok, it just wasn't clear to me what your point was. I already have the functionality on my end by adding the 4 lines of code to ripplelib mentioned above. My point was it would just help future developers to have those same 4 lines added in the official ripplelib.

[kuyawa]

Hey guys I'm also looking for a way to use 'deriveKeypair' and 'deriveAddress' so I did the same as /u/pftq but in one single line exposing the whole 'keypairs' module which is already included in the library (__webpack_require__(33)). I wish ripple devs allow the methods to be exposed since it is an easy change with no repercussions at all.

This way it would be easier for us to do:

// Modified ripple.js
var api = new ripple.RippleAPI()
var sec = api.keypairs.generateSeed();
var key = api.keypairs.deriveKeypair(sec);
var pub = api.keypairs.deriveAddress(key.publicKey);

[intelliot]

@kuyawa that’s a good idea. I think it might be even cleaner to expose the methods on api directly. Also, what do you think of https://github.com/ripple/ripple-lib/pull/830 ?

Want to contribute a PR? :)

[pftq]

That's the reason for the 4 lines I suggested (to expose it through the api variable).

On Fri, May 18, 2018 at 10:36 AM, Elliot Lee notifications@github.com wrote:

@kuyawa https://github.com/kuyawa that’s a good idea. I think it might be even cleaner to expose the methods on api directly. Also, what do you think of #830 https://github.com/ripple/ripple-lib/pull/830 ?

Want to contribute a PR? :)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ripple/ripple-lib/issues/770#issuecomment-390279069, or mute the thread https://github.com/notifications/unsubscribe-auth/ADWHgOpYIKYCPaOtsT9pnWfvafgvD2jEks5tzwaXgaJpZM4N0Udd .

[kuyawa]

Regarding #830 "Add ability to derive address from secret" exposing the keypairs module would allow to manage keys easily depending on the needs. I agree on allowing to derive the publick key from the secret so we don't have to ask for both pieces of information, which is the issue I am facing right now as a wallet developer, so a simple api.keypairs.deriveKeypair(secret).publicKey would suffice.

We developers don't want to have our hands tied and we also hate loading two heavy libraries that practically do the same, as ripple-keypairs is already loaded in ripple-lib as webpack(33).

[movitto]

PR #923 opened which should resolve this issue.

[mDuo13]

This has been fixed in #932 and released in v1.1.0.