cryptocoinjs / base-x Goto Github PK

The included https://github.com/cryptocoinjs/base-x/blob/master/src/index.d.ts differs from the one at https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/base-x/index.d.ts, which means, this introduces a breaking change.
Other packages (like bs58) use ^3.0.2 as their version string for this package, which will install 3.0.6 and break, because the other package doesn't expect such a breaking change in a patch release.

I would suggest unpublishing v3.0.6 and republishing it as 4.0.0, or overwriting v3.0.6 with the type definition of DefinitelyTyped.

Another more complicated option would be to overwrite 3.0.6 with 3.0.5 and republishing the package with your new typescript declaration under 4.0.0

you help me?

/home/pool/zcash/znomp/node_modules/base-x/index.js:52
if (string.length === 0) return Buffer.allocUnsafe(0)
^

TypeError: Cannot read property 'length' of undefined
at decodeUnsafe (/home/pool/zcash/znomp/node_modules/base-x/index.js:52:15)
at Object.decode (/home/pool/zcash/znomp/node_modules/base-x/index.js:81:15)
at Object.decode (/home/pool/zcash/znomp/node_modules/bs58check/index.js:44:23)
at Object.fromBase58Check (/home/pool/zcash/znomp/node_modules/bitcoinjs-lib-zcash/src/address.js:8:27)
at Object.exports.createGeneration (/home/pool/zcash/znomp/node_modules/stratum-pool/lib/transactions.js:97:52)
at new BlockTemplate (/home/pool/zcash/znomp/node_modules/stratum-pool/lib/blockTemplate.js:43:35)
at JobManager.processTemplate (/home/pool/zcash/znomp/node_modules/stratum-pool/lib/jobManager.js:150:32)
at /home/pool/zcash/znomp/node_modules/stratum-pool/lib/pool.js:588:66
at itemFinished (/home/pool/zcash/znomp/node_modules/stratum-pool/lib/daemon.js:155:36)
at /home/pool/zcash/znomp/node_modules/stratum-pool/lib/daemon.js:169:17

Is there a way to make base64 decoding work with padded input (= signs at the end) without significant changes?

The encode function assumes you are passing in a Buffer, but will happily accept a string with no errors. It will also return a valid looking result that does not decode back into the original string.

It would be helpful if this library threw some sort of exception back to the user if they passed an invalid input to the encode function.

@subliminator, you mentioned this in #1:

On a related note, I believe the way the leading zeroes are encoded is somewhat bitcoin style (doge, ripple, stellar, etc) address specific. Imagine if you used hex alphabet 0-F for example. You'd be forgiven for expecting each leading 0 to decode to 4 bits, but instead it would decode to a full byte.

I don't think that is true, do you have some test data to show case this?

my friend use base58 function in her react-native app. But the lastVersion base-x take an error for her app. The error is "undefined is not a function (evaluating 'BASE_MAP.fill(255)')"

I downgrade base-x to @3.0.4, everything is ok....I think this is a bug, so I issue it.

On README the indicated base32 alphabet is 0123456789ABCDEFGHJKMNPQRSTVWXYZ
But it should be ABCDEFGHIJKLMNOPQRSTUVWXYZ234567.

PS. Oh I also read that uses a different encoding. So it will always return a wrong value compared to other encoders.

The output should be 30 characters for anything below 0x088f924eeceeda7fe92e1f5b0fffffffffffffff.

0x01c5496aee77c1ba1f0854206a26dda82a81d6d8 is the following 30 characters: 7G1Y2YAHPUXSL8TQCWG49R290QSOUW.

Strangely 0x00c5496aee77c1ba1f0854206a26dda82a81d6d8 gets a 0 prefix making it 31 characters (which can be omitted and it decodes properly): 038O073KYGTWWZN0F2WZ0R8PX5ZPPZS

Any reason for base-x behaving this way? What is described in the README can be the cause, but it doesn't seem to be consistent, given a larger input number results in a smaller base-36 number.

Test code:

var BASE36_ALPHABET = '0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ'
var bs36 = require('base-x')(BASE36_ALPHABET)
var hex = require('convert-hex')

console.log(bs36.encode(hex.hexToBytes('00c5496aee77c1ba1f0854206a26dda82a81d6d8'))) // 038O073KYGTWWZN0F2WZ0R8PX5ZPPZS
console.log(bs36.encode(hex.hexToBytes('01c5496aee77c1ba1f0854206a26dda82a81d6d8'))) // 7G1Y2YAHPUXSL8TQCWG49R290QSOUW

Just to correct README.md when it says:

var decoded = bs58.decode('5Kd3NBUAdUnhyzenEwVLy9pBKxSwXvE9FMPyR4UKZvpe6E3AgLr')

console.log(decoded)
// => <Buffer 80 ed db dc 11 68 f1 da ea db d3 e4 4c 1e 3f 8f 5a 28 4c 20 29 f7 8a d2 6a f9 85 83 a4 99 de 5b 19>

Current implementation actually returns Array, not Buffer.

I noticed that the repo this was forked from contains this:
cryptocoinjs/bs58@01d308f

Could bs58 build off this module?

I just had several hours burned because I forgot this is not the case.

Whyyyyyyyyyy.

Can we just return a Buffer?

Yes, it would be a breaking change.

Hi base-x team! It is a simple error so I wont make it lengthy. I met some kind of this error Failed to minify the code from this file and it was base-x changed to use es6, to fix this error, could the team support babel or at least, just code it in es5 style?
Thanks team so much.

for (i = 0; string[i] === '1' && i < string.length - 1; i++) {

The comparison to '1' which is the first letter in the BTC alphabet. We basically want ALPHABET[0] of some form.

Cheers :)

So I would like to encode 128 bits consistently to 22 character in base58, but this is now always true. For example:

> const BASE58 = '123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz';
> const bs58 = require('base-x')(BASE58);
> bs58.decode('WDRoFqNxhwGYcnzDzasyY')
<Buffer 04 14 3a 63 2b 25 10 00 3f d0 46 31 cf e3 5a cf>
> 'WDRoFqNxhwGYcnzDzasyY'.length
21
> bs58.decode('PvctNaG977YY2NskPa4My6')
<Buffer b9 a5 95 ef f2 a0 27 8f db 85 fb 82 3e e9 a9 8d>
> 'PvctNaG977YY2NskPa4My6'.length
22

They are both 128 bits. I would like that this is always encoded to 22 characters. Is this possible somehow?

I feel that this implementation is different to base64 standard implementation. What happens?

A base45 (alphabet: 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ $%*+-./:) message was failing to decode in version 3.0.8 with the "Non-base45 character" error. It didn't make any sense, because I confirmed the message did not include any non-base45 character, but later concluded the problem was that the encoded message started with a space.

Through git bisect I found 2274e00 to be the first "bad" commit (introduced in version 3.0.5) -- though I don't understand why just by reading the code. But looking at 3.0.8 the problem is more obvious:

It's not even "skipping" spaces at the start, it's rejecting them.

The problem seems to be decoding only, not encoding, and only messages that start with a space when encoded (from my very limited experiments). Versions >=3.0.5 correctly encode e.g. a dollar ($) as a space ( ), but then error while decoding.

And this is what I tried:

$ sha512sum -b *random.bin | sort
72bf47abfcaf5460bfab86b5eee19fbd257dd3078b7d761dc1ff3beac37426e931b1a22b4b98db5bebb7e19a5fe93fc87d050ddf06cbf05ebffe288db756964a *encoded_3.0.2_decoded_3.0.2_random.bin
72bf47abfcaf5460bfab86b5eee19fbd257dd3078b7d761dc1ff3beac37426e931b1a22b4b98db5bebb7e19a5fe93fc87d050ddf06cbf05ebffe288db756964a *encoded_3.0.2_decoded_3.0.8_random.bin
72bf47abfcaf5460bfab86b5eee19fbd257dd3078b7d761dc1ff3beac37426e931b1a22b4b98db5bebb7e19a5fe93fc87d050ddf06cbf05ebffe288db756964a *encoded_3.0.8_decoded_3.0.2_random.bin
72bf47abfcaf5460bfab86b5eee19fbd257dd3078b7d761dc1ff3beac37426e931b1a22b4b98db5bebb7e19a5fe93fc87d050ddf06cbf05ebffe288db756964a *encoded_3.0.8_decoded_3.0.4_random.bin
72bf47abfcaf5460bfab86b5eee19fbd257dd3078b7d761dc1ff3beac37426e931b1a22b4b98db5bebb7e19a5fe93fc87d050ddf06cbf05ebffe288db756964a *encoded_3.0.8_decoded_3.0.5_random.bin
72bf47abfcaf5460bfab86b5eee19fbd257dd3078b7d761dc1ff3beac37426e931b1a22b4b98db5bebb7e19a5fe93fc87d050ddf06cbf05ebffe288db756964a *encoded_3.0.8_decoded_3.0.8_random.bin
72bf47abfcaf5460bfab86b5eee19fbd257dd3078b7d761dc1ff3beac37426e931b1a22b4b98db5bebb7e19a5fe93fc87d050ddf06cbf05ebffe288db756964a *random.bin
d51172558b9d62cb4ac9eb3dfc54fd56776670c80d570626116fb9eb59fa3e315ca961fc32037ad403005de054e363cfa05a9bfd800ccaf808329ab94324c0f3 *encoded_3.0.2_random.bin
d51172558b9d62cb4ac9eb3dfc54fd56776670c80d570626116fb9eb59fa3e315ca961fc32037ad403005de054e363cfa05a9bfd800ccaf808329ab94324c0f3 *encoded_3.0.8_random.bin

random.bin was created with dd if=/dev/urandom of=random.bin bs=1K count=1, and contained spaces in the middle of the encoded message, but not at the start.

@jprichardson here (bitcoinjs org) or https://github.com/cryptocoinjs?

@fanatid note https://github.com/uphold/bitcoin/blob/enhancement/speedup-encodebase58/src/base58.cpp#L80-L88 (from bitcoin/bitcoin#7656) it seems possible we could take advantage of this too.

Hi! It would be great if this lib could expose async api, because sometimes it can block js significantly.

It'd be awesome to be able to pass this to https://github.com/dominictarr/varstruct

We had to change for base16 on multibase, because base-x was not padding it correctly.

Now we found that base32 is also creating different bases than the ones other libraries generate. multiformats/js-multibase#17

Anyone else experiencing these issues as well?

It would be great to have an efficient C++ implementation for server usage. I'm not sure the logistics of that, but just throwing the idea out there.

any hope of support for browsers?

See: https://github.com/cryptocoinjs/base-x/blob/master/index.js#L81
Suggest something like: The character ${char} is not found in base${base} alphabet: ${alphabet}

May get around to a pull request myself at some point

Repost: cryptocoinjs/bs58#41 by @pundoo

on api example, it says :

input must be a Buffer or an Array

but gives error when running :

bs58.encode(new Uint8Array([1, 2])); or

bs58.encode([1, 2]);

bundled using browserify and running on chrome (latest version)

Hey! I noticed strange behavior. Does it match the plan or not?

https://codesandbox.io/s/bold-burnell-i3uil?file=/src/index.js

In one of the cases, the number of characters in the buffer is greater than the required one by 1. The data itself is correct, but at the beginning there is a parasitic zero.

I'm using a base58 encoding and I noticed that the encoded strings are not always the same length.
I have a desire for all encoded values to be the same length. Why is this? Is it necessary?

Here's a code example that results in a 21 character result instead of a 22 character result:

// create base58 encoder that uses only alpha numerics and leaves out O and 0 which get confused
const base58Encode = require('base-x')('123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz').encode;

const testData = Buffer.from([0x02, 0x3d, 0xab, 0x4f, 0x48, 0xcb, 0x79, 0xf9, 0x1c, 0x7e, 0x21, 0x97, 0xe7, 0xb1, 0xa0, 0x55]);

let str = base58Encode(testData);
console.log(str);

I'm using base-x to encode 96-bit random buffers to base 62. But the output length ia not constant because leading zeros are ignored.

I suggest to add an optional boolean parameter to encode: padd.
When true, the function will padd the result with leading zeros until its length is equal to

Math.ceil(bufferLength * 8 / Math.log2(base))

For the example above it'd be equal to 17.

I'm willing to write a PR, but wanted to get feedback on the proposed feature itself.

Package engine requirement makes base-x incompatible with AWS Lambda deployments. Lambda's current execution environment is Node LTS 4.3.2 and is not expected to move to LTS 6 until April 2017.

package.json : line 41

  "engines": {
    "node": ">=4.5.0"
  }

Is there any reason this cannot be revised back to 4.3.2?

Can you please make a new release which includes recent changes (the only real code change is 3b84684)?