Describe the bug
A sponsored tx is rejected with the message: Signer hash does not equal hash of public key(s): 710620ca0a2e47c6405c46f7fa0197db84dcdd27 != a9e0af73c2388abca8a8a1d349bf6e345676c6c6
The tx is build like this:
const network = new StacksTestnet();
network.coreApiUrl = http://localhost:20443;
const contractAddress = "ST000000000000000000002AMW42H"
const tx = await makeContractCall({
contractAddress,
contractName: "bns",
functionName: "name-transfer",
functionArgs: [
bufferCVFromString(namespace),
bufferCVFromString(name),
standardPrincipalCV(newOwner),
noneCV(),
],
fee: new BigNum(1000),
nonce: new BigNum(0),
network,
senderKey: privateKey,
sponsored: true
})
const sponsoredTx = await sponsorTransaction({
transaction: tx,
sponsorPrivateKey: secretKey,
network
})
What version of stacks.js are you using?
"@stacks/transactions": "^1.1.1-alpha.0",
Is the bug present in the Blockstack CLI, Gaia hub, Connect or Blockstack Browser?
"@stacks/transactions": "^1.1.1-alpha.0",
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Tx should not be rejected for signature hash problems.
Console log
Error: failed to handle transaction 22a74b93bcebc96f6615e4b49700c68af5dde243cdd2e9e1441244886266754d: {"error":"transaction rejected","reason":"SignatureValidation","reason_data":{"message":"Signer hash does not equal hash of public key(s): 710620ca0a2e47c6405c46f7fa0197db84dcdd27 != a9e0af73c2388abca8a8a1d349bf6e345676c6c6"},"txid":"22a74b93bcebc96f6615e4b49700c68af5dde243cdd2e9e1441244886266754d"}
Additional context
While trying to send a username to my own address (https://github.com/blockstack/docs/issues/989)
Maybe this is an issue with compressed and uncompressed keys (as discussed with @yknl )
Also running into this.
@reedrosenbluth @agraebe This came up as a moderately urgent item when meeting with @MarvinJanssen and @GinaAbrams yesterday. It appears they have a temporary workaround for the current lack of sponsored transactions support, but they'll likely need to implement sponsored transactions within the next few months given the operational costs of that workaround.
Is this an item that splat could investigate to see if there's a relatively easy fix?
Will take a look at this today!
The issue seems to be that sponsored transactions are failing if they are signed with _uncompressed_ private keys.
A quick workaround is to simply append 01 to the end of the private keys you are using.
For example, the private key b8d99fd45da58038d630d9855d3ca2466e8e0f89d3894c4724f0efc9ff4b51f0 would become b8d99fd45da58038d630d9855d3ca2466e8e0f89d3894c4724f0efc9ff4b51f001.
I'll work on a fix for this, as Stacks.js _should_ function properly with both _compressed_ and _uncompressed_ keys. Let me know if this workaround works.
@reedrosenbluth wouldn't I have to compress the private key first? Will simply appending 01 work for an existing setup?
@MarvinJanssen No, there is no such thing as a compressed ECDSA private key. The 01 at the end simply means that the public key should be generated in its compressed form.
Using keys with this compression byte should hopefully fix the problem you are having. In the future, Stacks.js should support both compressed and uncompressed keys.
@reedrosenbluth right I did not think it through before I posted. Will try this today.
@stacks/transactions v1.3.5 has been published