wip: CashAddr basic implementation #13

[mahnunchik]

Basic implementation of CashAddr encoding.

Specification: https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/cashaddr.md

Other implementations:

• https://github.com/bcoin-org/bstring/blob/master/lib/cashaddr-browser.js
• https://github.com/ealmansi/cashaddrjs/blob/master/src/cashaddr.js
• https://github.com/bcoin-org/bcash/blob/master/lib/primitives/address.js

Implementation details:

• BigInt is used in checksum calculation to handle bitwise operations on 5 * 8 bit numbers.
• convertRadix is used instead of convertRadix2 to convert number to checksum bits.
• I decided not to merge the implementations of bech32 and cashaddr because it brings many ifs and complicated logic.
• bech32 and cashaddr shares Bech32Decoded and Bech32DecodedWithArray interface. Should it be renamed or copied to a new one?
• cashaddr doesn't have length limit.
• Do I understand correctly that Version byte logic should be implemented in top level library like btc-signer?

TODO:

• more tests

[mahnunchik]

It is possible to implement convertRadix2 on bigints to use same method in bech32 and cashaddr but according to your comment it is 5x times slower. Should it be tested again in modern browsers?

[paulmillr]

Thanks. Will review asap and see what's up with radixes

[paulmillr]

This looks good, however, I have a question about scope applicability.

cashaddr seem to only be used in bch. In return, we're adding ~100 lines of code for it, which is a big LOC increase. It will also kinda invalidate the previous audit.

I want people to be able to build their own primitives on top of scure-base without hassle. The question is: can you copy-paste the code into a file of yours and depend on scure-base, re-using primitives from it? Or, are some primitives not exported externally?

[mahnunchik]

Bitcoin Cash is the only surviving alternative Bitcoin after a series of hard forks. Its usage is quite large. So it may be helpful to have alternative to https://github.com/ealmansi/cashaddrjs library which is really huge when build for the browser.

• PR doesn't change existing code, so it should not invalidate audit.
• At least convertRadix and convertRadix2 doesn't exported.
• Maybe there is sense to make the library modular like @noble/hashes?

[paulmillr]

So it may be helpful to have alternative to https://github.com/ealmansi/cashaddrjs

Yes, an alternative is helpful, my question is why should it be in scure-base and not in e.g. "micro-cashaddr" or any other name, hosted on your account? The package will depend on scure-base and will consist of just 90 lines of code, would be easily readable and auditable.

A custom package would have better discovery feature than having it as one of 30 scure-base algorithms.

PR doesn't change existing code, so it should not invalidate audit.

Currently, the whole file is audited. The more changes we add, the harder it becomes to know what's audited and what isn't. We keep a post-audit diff.

At least convertRadix and convertRadix2 doesn't exported.

Exposed in 33d1337. If you will publish your package, I can release 1.1.5 with it today.

[mahnunchik]

Yes, I think it is better to have custom package which includes version bytes logic.

[paulmillr]

1.1.5 with methods exposed are out.

[mahnunchik]

Initial implementation https://github.com/CoinSpace/cashaddr

Questions:

1. Should BECH_ALPHABET be exported by scure-base or not? It is copied for now https://github.com/CoinSpace/cashaddr/blob/master/index.js#L4-L7
2. Should concatBytes be exported to reuse? It will make this code one line less https://github.com/CoinSpace/cashaddr/blob/master/index.js#L172-L174

[paulmillr]

1 no 2 yes but placing more stuff into utils object affects tree shaking I guess