Feature request: add endian (le or be) argument to toString method.
Motivation: working with ed25519 curve from elliptic module there is an inconvenience.
ed25519 uses numbers in little endian order:
const EdDSA = elliptic.eddsa;
const ec = new EdDSA('ed25519');
// hex string in little endian order
const input = '70ee7dd55b7ae8922ed345adc0f5fcc6ccb93c673f38ca7900186efb277337ff';
const num = ec.decodeInt(input);
// utils.intFromLE(bytes)
// new BN(bytes, 'hex', 'le');
// used under hood
// make reduce by n
const reduced = num.umod(ec.curve.n);
There is no simple way to convert reduced number to hex string in little endian order.
// option 1
const output = ec.encodeInt(reduced);
// produces array of numbers in little endian
// option 2
const output = reduced.toString('hex');
// produces hex string but in big endian order
It would be consistent to have endian argument across all to* method: a.toArray(endian, length), a.toArrayLike(type, endian, length), a.toBuffer(endian, length).
I think it is better to have a look at this issue in case of different bytes order: Wrong padding in toString() function #198
Feature request: add
endian
(le
orbe
) argument totoString
method.Motivation: working with
ed25519
curve fromelliptic
module there is an inconvenience.ed25519
uses numbers in little endian order:There is no simple way to convert
reduced
number to hex string in little endian order.Current solution
Yep, it works, but it is a bit wired.
Additional context
It would be consistent to have
endian
argument across allto*
method:a.toArray(endian, length)
,a.toArrayLike(type, endian, length)
,a.toBuffer(endian, length)
.I think it is better to have a look at this issue in case of different bytes order: Wrong padding in toString() function #198