Is there a reason why .send() is not an available method for HD Wallets?
Edit: I'm trying to use .sendTransaction() now but seem to be running into txHash mismatch error..
Is there a suggested way for transfering eth from an HD?
Edit2:
Using ganache-cli for local eth client.
await mainWallet.sendTransaction({
to: wallet.address,
amount: amount
});
error: Error: Transaction hash mismatch from Provider.sendTransaction. (expectedHash="0xf6878651c3eefc608e4852a4fdcf28dd9319f950b78dfb0dcf6d726ab2dd153b", returnedHash="0xf9b4f394391c0f14b22337a0d496bc36d2c54f7fce2f061c4e98e3710afbe355")
How are you generating your HD Wallet? There should be no difference whether a wallet comes from a mnemonic or a private key.
Unless you are aiming for performance (e.g. generating thousands of HD wallet) you can use:
let wallet0 = Wallet.fromMnemonic(mnemonic, "m/44'/60'/0'/0/0");
let wallet1 = Wallet.fromMnemonic(mnemonic, "m/44'/60'/1'/0/0");
let wallet2 = Wallet.fromMnemonic(mnemonic, "m/44'/60'/2'/0/0");
If you need to generate many wallets, you can optimize this a little using:
let wallets = [];
let node = HDNode.fromMnemonic(mnemonic);
let baseNode = node.derivePath("m/44'/60')
for (var j = 0; j < 1000; j++) {
let node = baseNode.derive(j + "'/0/0");
wallets.push(new Wallet(node));
}
If you are using the v4 branch (i.e. next), you can also pass in a Wordlist for other languages to Wallet.fromMnemonic(mnemonic, path, language). By default it will use English (en), but Chinese, Italian, Japanese, Korean and Italian are also supported... The remaining languages are coming soon.
when generating a large batch of wallets I'm using this:
let wallets = [];
const hd = ethers.HDNode.fromMnemonic(seed);
for (let i = 0; i < num; i++) {
const wallet = hd.derivePath(`m/44'/60'/0'/0/${i}`);
wallet.provider = provider;
wallets.push(wallet);
}
But i changed my code up:
mainWallet is being created via - const mainWallet = new ethers.Wallet(privKey, provider);
Yet I'm still getting a complaint that .send() is not a function and sendTransaction() gives me a mismatch error.
EDIT:
I am using @next
In v4, there is no Wallet.prototype.send, it was just a shorthand for sendTransaction( { to: address, value: amount }).
What provider are you using? The mismatch indicates that the signed and serialized transaction was mutated by the provider. Basically, when sendTransaction(rawTransaction) is called, it computes the transaction hash, and calls the provider; that error means the transaction hash returned by the provider does not match the hash computed...
Can you print out the error parameters:
console.log("Error", error.expectedHash, error.returnedHash);
In v4, there is no Wallet.prototype.send, it was just a shorthand for sendTransaction( { to: address, value: amount }).
Very sneaky. Nice little gothcya haha
I'm using ganache-cli just working localy right now...
Error: Transaction hash mismatch from Provider.sendTransaction. (expectedHash="0xe46a0e9bfb4de6e97e3c188f4b4dd99e5816f954a0b106030be56d1009e796e5", returnedHash="0xf9b4f394391c0f14b22337a0d496bc36d2c54f7fce2f061c4e98e3710afbe355")
EDIT:
Provider setup -> ethers.providers.JsonRpcProvider('http://127.0.0.1:8545');
Yeah, it just added more confusion than anything else, since people would try passing a transaction into send.
Ganache does a lot of weird things... Hmmm. Do you by chance have access to the raw transaction? If not, can you maybe add a console.log(signedTransaction) in the node_modules/ethers/providers/base-provider.js inside the BaseProvider.prototype.sendTransaction method?
@ricmoo had a bit of an ah-ha moment. I assumed it would auto-sign the TX for me. Although I'm getting an invalid tx object. Am i required to specify everything (nonce, gasLimit, gasPrice, etc..)?
EDIT:
I wonder if theres a way to offer better error handling if the tx hasn't been signed. I could look into that if you'd like.
If you use sendTransaction, all unspecified values will be fetched for you (i.e. nonce, gasPrice, gasLimit and chain ID). You can of course override anything you'd like.
If you use sign, nothing will be auto-populated.
But I think you are using sendTransaction, so everything should be a-ok.
Ok that makes sense why the tx object was incorrect. I'm starting to wonder if this is a ganach-cli issue...
I'm using sendTransaction as expected
const tx = {to: ethers.utils.computeAddress(wallets[i].publicKey), amount: amount};
console.log(tx) // { to: '0x58461B4BfF231097B0f4c4780161Ffa9Ec261a2A', amount: '9090581818181818181' }
await mainWallet.sendTransaction(tx);
But i keep encountering this bizarre error
Error: Transaction hash mismatch from Provider.sendTransaction. (expectedHash="0x6228a2731a0c5aa555c75c58090ca682fe1ba324d257296d0e5e7d1703fbbe11", returnedHash="0x20e675d184fd4d67910451d06316dfa5477fb177d5caa30f779e0fa0b6f6e12a")
My guess is that ganache is unpacking the signed transaction, changing some values, then re-signing it...
Try creating a new Wallet, (e.g. new Wallet('0x123456789012345678901234567890123456789012345678901234567890123')) and sending ether in Ganache to that wallet. Then use it instead. That way Ganache doesn't have the private key and hopefully won't be able to be "clever".
I gave that a shot, but it seems that every transaction i attempt gives me a mismatch.. I'm going to give it a shot in the morning and get back to you.
Ok...
One more thing to check, try a get provider.getTransaction(error.returnedHash) to see what is different from the transaction you sent vs. the one it mined.
@ricmoo I'm so sorry that i wasted your time..
Went for a hail mary and it did the tricknpm update -g ganache-cli
LOL!
No worries... Most of the issues I help out with are either a bug in ganache or a bug in truffle. :)
Well, that was fun.. hahaha.
Thanks for hanging around for so long, really appreciate it!
For anyone else who comes across this:
I experienced the same issue with [email protected] paired with [email protected]. Downgrading to [email protected] fixed the issue.
(I also experienced a sporadic "incorrect nonce" type error, where the transaction nonce was different from the account's nonce, which I'm currently unable to reproduce. This problem also seems to have been resolved by downgrading to [email protected])
@andrewgordstewart thank you for that man, you saved me! Made a ticket on the Ganache issue tracker too.
Most helpful comment
For anyone else who comes across this:
I experienced the same issue with
[email protected]paired with[email protected]. Downgrading to[email protected]fixed the issue.(I also experienced a sporadic "incorrect nonce" type error, where the transaction nonce was different from the account's nonce, which I'm currently unable to reproduce. This problem also seems to have been resolved by downgrading to
[email protected])