Wrong schnorr signature with default extra data

[vserpokryl]

Example:

import * as eccTiny from 'tiny-secp256k1';
import * as eccLab from '@bitcoinerlab/secp256k1';

const h = Buffer.from('1bc291f3bef841a0fdb513ef5e4cb4d1a5e85b20f605643a254ee0f7bc108e35', 'hex');
const d = Buffer.from('49d8ac1e3da79419258e030e45a93836759aa6c387ef3ec043def5bd9b175d68', 'hex');

const signatureTiny = Buffer.from(eccTiny.signSchnorr(h, d)).toString('hex');
const signatureLab = Buffer.from(eccLab.signSchnorr(h, d)).toString('hex');

console.log(signatureTiny, 'signatureTiny'); // 13e5d2b0f445424fddda7b5c47dbab46c8dc08beeafe62d225e2f7d141694eae9367080ada0604bee46988d825e9f4779d74fdbb442ad87e14c080ef6465bb66
console.log(signatureLab, 'signatureLab'); // ceecf856754fe028360c0fda4e0381c9383d9c3ed0ad2e2a247d56948c4d88e28789692a28fc9f6ed9ed30f14fabe2f7282e5e43dbe6fc51d1b23f7783fb1227
console.log(signatureTiny === signatureLab); // false

For example bip-schnorr also return the same result as tiny-secp256k1

var bipSchnorr = require("bip-schnorr");

const privateKeyHex = '49d8ac1e3da79419258e030e45a93836759aa6c387ef3ec043def5bd9b175d68';
const message = Buffer.from('1bc291f3bef841a0fdb513ef5e4cb4d1a5e85b20f605643a254ee0f7bc108e35', 'hex');
console.log(bipSchnorr.sign(privateKeyHex, message).toString('hex')); // 13e5d2b0f445424fddda7b5c47dbab46c8dc08beeafe62d225e2f7d141694eae9367080ada0604bee46988d825e9f4779d74fdbb442ad87e14c080ef6465bb66

[landabaso]

I am currently working on finding a solution to maintain consistency across libraries. Please note that the computed signature is valid and can be safely used. However, in the meantime, I have made an update to the package. It now includes a warning message that will be displayed when the function is executed without an auxRand value.

[landabaso]

It appears that @noble (and by extension, @bitcoinerlab/secp256k1) are producing correct signatures according to the specifications. However, the signatures produced by libsecp256k1 and bip-schnorr might not be fully conforming to the spec. I'll close this issue for now, but I'll continue to monitor the discussion at:

paulmillr/noble-curves#61 (comment)

I'll update this issue if new information becomes available that impacts @bitcoinerlab/secp256k1.

[landabaso]

Everything has been clarified. @vserpokryl, you can find additional details about the discrepancy in this issue.