The documentation states entropy must be "at least" 16 bytes long, suggesting longer arrays will be accepted and utilised. However, the code truncates supplied arrays of length>16 to the first 16 bytes, without returning an error.

Which is the correct behaviour?

As it stands, the module may be supplied with a large array of entropy in good faith, only to have this reduced to the first 16 bytes without notification. A user of the module may be lead to believe seeds are being generated with a greater amount of entropy than is in fact taking place.

Discussion: #94 (comment)

This is a breaking change and will be made for v2.0.0

The deriveKeypair method takes a seed and derives the public and private key. We should add a method, perhaps derivePublicKey, that takes a private key and derives a public key. One complication is that we support two different algorithms: ecdsa-secp256k1 and ed25519. Given a private key, I don't think there is a way to know whether it is meant to be used as a secp256k1 key or an ed25519 one. So this would need to be determined by another parameter passed into the method (along with the private key data).

Follow-up to #82

• We want to verify that we are generating correct validator keys
• The minimum would be to ensure the keys work when used with rippled
• The reference implementation is rippled and/or https://github.com/ripple/validator-keys-tool
• Note that rippled doesn’t support Ed25519 validator keys yet but it’s something that will eventually be added and we should (if possible) ensure we’re compatible with that when it does happen

Currently seed <-> secret, base58 chosen to encode payload, with outer frame encoding version
publicBytesCanonical() - return pub key in form for SigningPubKey with 0xED prefix
reconsider sign(message, seed) - may not be textbook but currently seed <--> secret

Hi Team,
Iget this error when install the npm dependencies ::

npm ERR! Test failed.  See above for more details.
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] prepublish: `npm test && npm run lint && npm run compile`

Per #30 (comment) we can probably get rid of Babel.

We are on [email protected] but elliptic and ripple-binary-codec and webpack are on [email protected]. We should update.

Please add LICENSE file.

Hi guys,

I'm not that familiar with npm, but I was surprised that the elliptic crypto libraries were project dependencies. Pulling elliptic as a versioned dependency puts trust in the upstream developers to "get it right". Why don't you simply add the upstream elliptic.js source to this repo?

Steve

This is my package.json after npm install [email protected]:

{
  "_from": "ripple-keypairs@latest",
  "_id": "[email protected]",
...
  "dependencies": {
    "babel-runtime": "^5.8.20",
    "bn.js": "^3.1.1",
    "brorand": "^1.0.5",
    "elliptic": "^6.4.0",
    "hash.js": "^1.0.3",
    "ripple-address-codec": "^2.0.1"
  },
  ...

It has an outdated version of a dependency:

"ripple-address-codec": "^2.0.1"

that relies on a deprecated x-address-codec. This package uses [email protected] which conflicts with the latest base-x versions. Is it possible to update the npm released version with the dependencies on master (or a beta release)? There should be no code change needed, just a npm release update.

Hi, I use the library to sign the same message with same seed, it always get the same signature, I check the code, every time it create the same K, as I understand for the ECDSA, the k should be variant, right?

ripple-address-codec already uses Jest, and Jest seems to be the new standard JS test runner, so we should migrate to that when we have time.

looking for the proper syntax for ed25519 seed generation and if there is anyway to confirm after the fact that ed25519 was in fact used.

I ask because this produces a seed:
keypairs.generateSeed(algorithm="ed25519")

but this also does:
keypairs.generateSeed(algorithm ="12312ed25519");

which makes me think I have it wrong,
thanks in advance

EDIT: should be:
keypairs.generateSeed({algorithm: "ed25519"});

and confirm with ripple-address-codec decodeSeed(seed)

There's a 3rd party library for this: https://www.npmjs.com/package/ripple-sign-keypairs

But I think it would be reasonable to add this feature into ripple-keypairs directly.

The goal is to enable someone to sign using bip39/bip44 or bip32 derived keys, including multisig use cases.

• ESLint gets upset because we don't specify return types on any of our functions.
• Almost everything in ripple-keypairs is of type any. We should enable the noImplicitAny rule in tsconfig.json and add better types for this library.

Better types make it easier to refactor code, and provide useful information to downstream consumers of the library.

As part of this, we'll want to install typings for our dependencies that don't bundle them:
https://www.npmjs.com/package/@types/elliptic
https://www.npmjs.com/package/@types/brorand

Additionally, we may want to switch the call signatures of functions that return Hex strings to just returning an array of bytes (Buffer or Uint8[])

Currently all the tests are written in JS, but there's no reason they can't be in TypeScript like all the source files.

This would bring ripple-keypairs in line with ripple-lib.

Hello everyone. A transaction made on dex. When check hash it says transaction was successful. But never received tokens. What should I do.

The hash to the transaction is below. Any thoughts

4FF465B7DD741C2B77AE285C31F9BE12DE8B375B3F420B4DF80096F090B5B8BC

Right now, it's possible to use deriveAddress(publicKey) to get a user's address. It would also be nice to have the opposite function available, generating public keys from a given address.

The default linter for Typescript is now ESLint and TSLint is deprecated. We should take the time to replace our linter.

We're really close, and we just need to write a few more tests to get there. This is also a good opportunity to review the tests that already exist and see if they are robust enough / test the right things.

Being at 100% coverage would be great because it makes it clear if there's a testing regression, and it ensures we aren't shipping functionality that is untested.

I have publishkey/privatekey from bip32/bip39/mnemonic
But the ripple-lib use the secret to submit a payment.
Can you tell me how to get these?
thank you so much!

How to verify signed data which have only signature(hexadecimal string), address, and data, I mean message

Discussion: #94 (comment)