Works with React Native?

[ffxsam]

Does anyone know if this library will work with React Native? Theoretically any JS could should, but I wanted to know if it would operate securely, or if there were any caveats.

[dcousens]

That is a good question. I don't have the answer for you, maybe @jprichardson does.
However, the steps to testing would be:

• Attempt to run the test suite in React Native
• Investigate React Native's secure random number generation source
• Run the Buffer test suite

If the results of those two three steps are satisfactory, then I think you'd be probably be OK to use this library 👍

[jprichardson]

I don't have the answer for you, maybe @jprichardson does.

Unfortunately I don't either, I haven't been able to use React Native yet 😞 However @mvayngrib may know.

[mvayngrib]

bitcoinjs-lib works fine in react native. Currently you'll need rn-nodeify, at least until this issue is resolved.

re: random number generation, the async rng uses iOS's SecRandomCopyBytes, the sync one uses a sjcl's rng seed with SecRandomCopyBytes. You'll need to evaluate the security of that for yourself.

[dcousens]

@mvayngrib that is interesting that they are different.

[mvayngrib]

@dcousens yep, javascript only has async access to native functions

[mvayngrib]

you'll need a piece of native code to make that work, but react-native-randombytes basically does those five lines for you:
js: https://github.com/mvayngrib/react-native-randombytes/blob/master/index.js#L39
objc: https://github.com/mvayngrib/react-native-randombytes/blob/master/RNRandomBytes.m

[ffxsam]

This thread is a gold mine. Thanks!

[dcousens]

ping @39otrebla, were you having issues with this?

https://github.com/39otrebla/react-native-bitcoinjs-lib implies you had issues, but I can't see any difference except the .gitignore...

[39otrebla]

@dcousens yeah had some issues, randomBytes does not work on ReactNative out of the box, as well as node-dependent packages.. I did need some workarounds, but now it works perfectly

EDIT: differences are in ecpair.js, where I include react native randombytes package instead of node randombytes .. also, things like Buffer and streams does not work on React Native out of the box, you do need to use rn-nodeify.. The README of https://github.com/39otrebla/react-native-bitcoinjs-lib explains all step by step

[dcousens]

@39otrebla can you think of a way we could incorporate support into this library without you needing to maintain/rebase a separate fork?

[dcousens]

@39otrebla any reason why you didn't just pass in your own rng parameter?
Or did randombytes as a package fail to import entirely?

[dcousens]

@jprichardson @mvayngrib @calvinmetcalf @dominictarr @feross @fanatid

tl;dr: If we all used require('buffer') around the place we could claim this library, and many others, as react-native compatible. (and the ability to always pass in an RNG)

Thoughts?

It would require quite a few changes upstream to various dependencies.

I know this problem shouldn't be our responsibility, but at the same time it is just a nasty side effect of nodes implicit "non-standard" JS globals.

We took the approach in https://github.com/crypto-browserify to use require('create-hash') instead of require('crypto') as a way to reduce require bloat.

Maybe we can take the same initiative here (except in allowing for just a plug-and-play approach for new tools such as react-native).

edit: actually, maybe disregard, this is just totally not our problem?

[mvayngrib]

@dcousens i think the initiative mostly belongs on the react-native packager end, to enable shimming / resolve-aliasing a la browserify and webpack. I currently use bitcoinjs-lib and other libs with rn-nodeify's hackery, and a bunch of native shims i co-developed with other react native fans. @philikon has developed https://github.com/philikon/ReactNativify, which is a healthier approach, but one I haven't tested yet. I suggested to him recently to try it out on bitcoinjs-lib and he said it worked: https://github.com/mvayngrib/rn-nodeify/issues/25#issuecomment-277853745

also see: https://productpains.com/post/react-native/packager-support-resolvealias-ala-webpack

[dominictarr]

I'd be happy to merge a pr adding explicit require('buffer') to any of my modules, though I think there may be a lot of them, and a better way would be if

[dcousens]

@dominictarr

and a better way would be if

if? 😃

[dominictarr]

sorry ... if a pull request was made to react-native to support Buffer

[dcousens]

@dominictarr I'm thinking of re-visiting this one - maybe adding require('buffer') unanimously...
Its a tiny change - no other impact - and allows us to get past this.

I know it is not great, but, maybe Buffer as a global was a dumb idea anyway?

[dominictarr]

@dcousens lets do it

[dcousens]

Closing in favour of #797