"ecc library invalid" when initializing ECPairFactory

[bucko13]

There may be some overlap here with another issue I found when trying to initEcc in bitcoinjs-lib with tiny-secp256k1. I put up a fix for that here but even with this I started running into a similar error when trying to init the same library with ecpair. I.e. the same ecc library will init and validate with bitcoinjs-lib but not ECPairFactory. You can see both being initialized in this WIP PR here and the failure in CI here.

In an attempt to narrow down what was causing the failure, I went through each assertion in testecc to find the ones that would fail. By commenting out pointFromScalar, sign, and signSchnorr in the built code in my node_modules, I was able to get the library to verify and use ECPairFactory without problem though it's not clear to me why these are failing (and skipping validations is obviously not ideal).

When consoling out what the assertion was expecting versus what it was getting, this is what I found for pointFromScalar:

actual: <Buffer 03 cd e1 d8 c4 fb e5 ee 21 ff 86 51 5c a7 8d e4 c7 14 d1 cb 8e 60 c0 22 b8 5b 8c cf 6f 83 55 ac b6>
expected: <Buffer 02 b0 7b a9 dc a9 52 3b 7e f4 bd 97 70 3d 43 d2 03 99 eb 69 8e 19 47 04 79 1a 25 ce 77 a4 00 df 99>

I'm getting this in node environments (jest tests specifically) as well as an esbuild/vite build for browser.

There is a branch with code that reproduces this here with the relevant file here and tests here.

[bucko13]

Note that if I use an older version of bitcoinjs-lib (^5.1.10) for just ECPair and signature validation then everything works fine as well. I'll probably end up doing that for now to unblock enabling spend to taproot transactions but ideally we can upgrade everything when possible.

Update: reverted here so some of the original links might not be up to date, but you can see what it looked like when breaking the ecc lib validation.

[junderw]

I feel like bitcoinjs/bitcoinjs-lib#1855 will fix these issues.

It seems like the discrepancy is born out of certain runtimes treating the different byte array types differently.

It seems like all the frontend runtimes are moving forward with a "Buffer never existed, so bugs involving it should be ignored." stance on the issue... so the only long term solution is to pretend Buffer never existed I guess.

[bucko13]

Oh nice. that's good there's a fix in the works.

And yeah, my understanding is that Buffer is just a node thing and so the polyfill libraries that allow support for multi-environments just replace Buffer with Uint8Array.