canonical signature support for secp256k1

[ceeji]

• I'm submitting a ...
  [ ] bug report
  [*] feature request
  [ ] question about the decisions made in the repository
  [ ] question about how to use this project

• Summary
  For steem, EOS and everiToken blockchain, a canonical signature is needed for transactions. By calling libsecp256k1 directly I can make it by passing a noncefn parameters for signing and in passed function I can return a series of incresed nonces until generated signature is canonical (that is, both r and s of the signature have a length of 32 byte. that is, in a der signature array, der[3] == der[37] == 32 ).

But I can't do it with bitcoin-ts. There is no way to pass noncefn, and the signature produced by bitcoin-ts is not canonical.

The requirements are widespread for developers of these blockchains, therefore I think it's necessary to add it to the library. If it couldn't be done in the near future, is there a way to modify the code to achieve this by myself?

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. StackOverflow, personal fork, etc.)

[bitjson]

@ceeji thanks for submitting an issue!

Somehow I hadn't encountered that use case before – thanks for the info! I didn't spend a lot of time tinkering with the noncefn parameter in the first release because I didn't need it myself, but I'd love to get it working in this library.

There's a note about it here, and that's the file that would need to be modified. (Here's the code that calls the compiled WASM method.)

I'm not sure how/if Emscripten supports providing that parameter, so it might take some experimenting. Here's where we build the WebAssembly in the yarn compile:secp256k1 task.

I didn't explicitly remove or disable, the parameter, so I think the WASM still accepts a noncefn parameter there. How it's used, I have no idea. 😅You might need to ask in IRC or on the mailing list.

Looks like this might be helpful too: Function Pointer Issues

I won't be able to look into this for a while, but I'd love to take a pull request enabling it!

Or if someone could just figure out how the noncefn parameter can be provided from WASM, I'm happy to implement it, write the tests, documentation, etc.

[ceeji]

Great! I will refer to the links and see if it works

[ARitz-Cracker]

Hello! I've wanted to share my success on making C code in WASM call a JS function. Implementing this isn't necessary for my needs, but I've got something that should point someone who's willing to do the grunt work in the right direction.

First, we can add -s RESERVED_FUNCTION_POINTERS=1 to the emcc command parameters.

Next we store a callable pointer in C like what I've done here

After that, we call the set function and set the pointer to 1 as we have 1 reserved function pointer. (Or you can literally just pass 1 as the noncefn parameter.)

Now, when compiling emcc with RESERVED_FUNCTION_POINTERS, it will complain that a jsCall_xxxx function must be provided in env when you try to WebAssembly.instantiate it. This function will be called with parameters (0, ...args) where args is what you passed in C.

Since the calls to secp256k1Wasm are synchronous, you can store the callback function provided by consumers for jsCall_xxxx to call like what I've done here here and here

It does seem that RESERVED_FUNCTION_POINTERS=x literally reserves x pointers from the beginning of the memory space. So the reason why I've got an array in my implementation is because I realized that if you have more than 1 RESERVED_FUNCTION_POINTERS, the jsCall_xxxx's first parameter gets called with the function pointer it called minus 1. Which leads me to believe that the function pointers are intended to be linked to an array of callback functions, (which is indeed the case with the .js file emcc auto-generates) and I want to use that code base for a generic wasm binary loader in the future.