Web3.js: Signing Transactions fail with Locally created Accounts.

Created on 22 Jul 2017  Â·  22Comments  Â·  Source: ChainSafe/web3.js

i have successfully managed to create a local account, add it to wallet, unlock it and then transfer ether to it. Now, what i wanted was to send this ether from the unlocked local account to another but i always error out. Yet sending ether between the default accounts from getAccounts() always works.. my guess is that maybe it fails on signing using the new local accounts. below is my code and error i get

var web3 = new Web3('http://localhost:8545');
var accounts;
var fromAddress;
web3.eth.getAccounts().then(function(o) {
    accounts = o;
    //fromAddress previously created by createAccount with password of 'newjordah' and loaded with ether
    fromAddress = "0xD7325762c8017ff83d474AAa0ca266f178e1813c";
    loadAccount("newjordah");
    var toAddress = accounts[1];
    sendEth(fromAddress, toAddress, 0.1);
});

function sendEth(_from, _to, _amount) {
    web3.eth.sendTransaction({
        from: _from,
        to: _to,
        value: web3.utils.toWei(_amount, 'ether'),
        gas: '0x2710'
    }).then(function(receipt) {
        console.log(receipt);
    });
}

function createAccount(_password) {
    var nObj = web3.eth.accounts.create();
    web3.eth.accounts.wallet.add(nObj);
    web3.eth.accounts.wallet.save(_password);
    return nObj;
}

function loadAccount(_password) {
    try {
        var l = web3.eth.accounts.wallet.load(_password);
        console.log("Account Unlocked")
        return l;
    } catch (e) {
        console.log(e);
    }
}

i get this error


web3.min.js:1 Unhandled rejection RangeError: Maximum call stack size exceeded
    at String.slice (native)
    at t (file:///C:/Users/Jordah/Desktop/react/ewallet/lerna-repo/dist/web3.min.js:1:620555)
    at t (file:///C:/Users/Jordah/Desktop/react/ewallet/lerna-repo/dist/web3.min.js:1:620543)
    at t (file:///C:/Users/Jordah/Desktop/react/ewallet/lerna-repo/dist/web3.min.js:1:620543)
    at t (file:///C:/Users/Jordah/Desktop/react/ewallet/lerna-repo/dist/web3.min.js:1:620543)
    at t (file:///C:/Users/Jordah/Desktop/react/ewallet/lerna-repo/dist/web3.min.js:1:620543)
    at t (file:///C:/Users/Jordah/Desktop/react/ewallet/lerna-repo/dist/web3.min.js:1:620543)
    at t (file:///C:/Users/Jordah/Desktop/react/ewallet/lerna-repo/dist/web3.min.js:1:620543)
    at t (file:///C:/Users/Jordah/Desktop/react/ewallet/lerna-repo/dist/web3.min.js:1:620543)
    at t (file:///C:/Users/Jordah/Desktop/react/ewallet/lerna-repo/dist/web3.min.js:1:620543)
    at t (file:///C:/Users/Jordah/Desktop/react/ewallet/lerna-repo/dist/web3.min.js:1:620543)
    at t (file:///C:/Users/Jordah/Desktop/react/ewallet/lerna-repo/dist/web3.min.js:1:620543)
    at t (file:///C:/Users/Jordah/Desktop/react/ewallet/lerna-repo/dist/web3.min.js:1:620543)
    at t (file:///C:/Users/Jordah/Desktop/react/ewallet/lerna-repo/dist/web3.min.js:1:620543)
    at t (file:///C:/Users/Jordah/Desktop/react/ewallet/lerna-repo/dist/web3.min.js:1:620543)
    at t (file:///C:/Users/Jordah/Desktop/react/ewallet/lerna-repo/dist/web3.min.js:1:620543)
    at t (file:///C:/Users/Jordah/Desktop/react/ewallet/lerna-repo/dist/web3.min.js:1:620543)
    at t (file:///C:/Users/Jordah/Desktop/react/ewallet/lerna-repo/dist/web3.min.js:1:620543)
    at t (file:///C:/Users/Jordah/Desktop/react/ewallet/lerna-repo/dist/web3.min.js:1:620543)
    at t (file:///C:/Users/Jordah/Desktop/react/ewallet/lerna-repo/dist/web3.min.js:1:620543)
    at t (file:///C:/Users/Jordah/Desktop/react/ewallet/lerna-repo/dist/web3.min.js:1:620543)
    at t (file:///C:/Users/Jordah/Desktop/react/ewallet/lerna-repo/dist/web3.min.js:1:620543)
From previous event:
    at i.d [as _captureStackTrace] (file:///C:/Users/Jordah/Desktop/react/ewallet/lerna-repo/dist/web3.min.js:1:490583)
    at i._then (file:///C:/Users/Jordah/Desktop/react/ewallet/lerna-repo/dist/web3.min.js:1:519672)
    at i.then (file:///C:/Users/Jordah/Desktop/react/ewallet/lerna-repo/dist/web3.min.js:1:518042)
    at m.signTransaction (file:///C:/Users/Jordah/Desktop/react/ewallet/lerna-repo/dist/web3.min.js:1:676651)
    at f (file:///C:/Users/Jordah/Desktop/react/ewallet/lerna-repo/dist/web3.min.js:1:337277)
    at Object.callback (file:///C:/Users/Jordah/Desktop/react/ewallet/lerna-repo/dist/web3.min.js:1:337826)
    at u (file:///C:/Users/Jordah/Desktop/react/ewallet/lerna-repo/dist/web3.min.js:1:336909)
    at file:///C:/Users/Jordah/Desktop/react/ewallet/lerna-repo/dist/web3.min.js:1:417689
    at XMLHttpRequest.o.onreadystatechange (file:///C:/Users/Jordah/Desktop/react/ewallet/lerna-repo/dist/web3.min.js:1:703384)
bug
Source
picture sirlojik
👍1

Most helpful comment

So, as the stack trace suggests, the max call stack size is being exceeded by an infinite execution loop of the pad function in eth-lib/bytes. This function is called by the makeSign function in eth-lib/accounts like so:

Bytes.pad(1, Bytes.fromNumber(addToV + signature.recoveryParam))

The issue seems to be that addToV can be a pretty large number (Nat.toNumber(tx.chainId || "0x1") * 2 + 35) when using TestRPC (chainId will be something like 1504787153407 unless set using the --network-id option). So, the hex value initially passed to Bytes.pad will have a length of 12 and on the second pass a length of 15. The infinite loop is then entered because the condition inside Bytes.pad will never be true (hex.length === 4):

const pad = (l,hex) => hex.length === l*2+2 ? hex : pad(l,"0x"+"0"+hex.slice(2));

If I change l to be 16 the function will return successfully. However, I'm not sure if this is the correct solution/what side effects this may cause as I do not have enough understanding of the web3.js library.

On a side note, this calculation of v will cause users of TestRPC to encounter this bug. Running TestRPC with a custom, small network ID should resolve this for now testrpc --network-id 10.

picture lukehedger on 7 Sep 2017
👍6

All 22 comments

This is beta so please be careful when sending ether. I will have a look.
could you state your OS etc?

frozeman picture frozeman on 22 Jul 2017

@MaiaVictor i checked my code, and this must happen inside the signing process itself.
@sirlojik can you please build the source files yourself and use the none minified version?
clone the repo and run gulp and use the dist/web3.js

frozeman picture frozeman on 22 Jul 2017

@frozeman I think I have encountered the same issue as @sirlojik whilst attempting to sign a transaction using a privateKey generated with web3.eth.accounts.

Version: 1.0.0-beta.18
OS: macOS Sierra 10.12.4
Browser: Chrome 60.0.3112.101
TestRPC: 4.1.1 (ganache-core: 1.1.2)

const account = web3.eth.accounts.create()

myContract.methods.myMethod()
  .then(tx => tx.encodeABI())
  .then(abi => account.signTransaction({ data: abi, gas: 4700000, to: contractAddr })) // errors here
  .then(signedTx => web3.eth.sendSignedTransaction(signedTx.rawTransaction))

This is the error caused by account.signTransaction(): https://gist.github.com/lukehedger/1e9a786eb557bd3b42d760964736c641

lukehedger picture lukehedger on 30 Aug 2017

So, as the stack trace suggests, the max call stack size is being exceeded by an infinite execution loop of the pad function in eth-lib/bytes. This function is called by the makeSign function in eth-lib/accounts like so:

Bytes.pad(1, Bytes.fromNumber(addToV + signature.recoveryParam))

The issue seems to be that addToV can be a pretty large number (Nat.toNumber(tx.chainId || "0x1") * 2 + 35) when using TestRPC (chainId will be something like 1504787153407 unless set using the --network-id option). So, the hex value initially passed to Bytes.pad will have a length of 12 and on the second pass a length of 15. The infinite loop is then entered because the condition inside Bytes.pad will never be true (hex.length === 4):

const pad = (l,hex) => hex.length === l*2+2 ? hex : pad(l,"0x"+"0"+hex.slice(2));

If I change l to be 16 the function will return successfully. However, I'm not sure if this is the correct solution/what side effects this may cause as I do not have enough understanding of the web3.js library.

On a side note, this calculation of v will cause users of TestRPC to encounter this bug. Running TestRPC with a custom, small network ID should resolve this for now testrpc --network-id 10.

lukehedger picture lukehedger on 7 Sep 2017
👍6

@lukehedger Good catch. I'm getting the same error with a private dev geth node using network-id > 40,000, but can confirm this function works on Ropsten where network-id == 3.

cmditch picture cmditch on 11 Sep 2017
👍3

I have the same issue. This makes impossible to use web3.js with geth run in the development mode (get --dev) - it imposes chainID to be 1337. Then to comply with EIP155 one need to set same networkID, otherwise we will get Invalid Sender errors.

robert-zaremba picture robert-zaremba on 26 Sep 2017

So the @lukehedger workaround is good. However It's pretty limited for geth - as far I didn't found any option to make geth with custom genesis block as fast as geth --dev. Any ideas?
https://ethereum.stackexchange.com/questions/27119/what-are-the-equivalent-options-to-geth-dev

robert-zaremba picture robert-zaremba on 26 Sep 2017

Running TestRPC with a custom, small network ID should resolve this
for now testrpc
--network-id 10.

This solved the issue for me too. Everything is working as expected

On Thu, Sep 7, 2017 at 3:42 PM, Luke Hedger notifications@github.com
wrote:

So, as the stack trace
https://gist.github.com/lukehedger/1e9a786eb557bd3b42d760964736c641
suggests, the max call stack size is being exceeded by an infinite
execution loop of the pad function in eth-lib/bytes
https://github.com/MaiaVictor/eth-lib/blob/master/src/bytes.js#L37.
This function is called by the makeSign function in eth-lib/accounts
https://github.com/MaiaVictor/eth-lib/blob/master/src/account.js#L48
like so:

Bytes.pad(1, Bytes.fromNumber(addToV + signature.recoveryParam))

The issue seems to be that addToV can be a pretty large number (Nat.toNumber(tx.chainId
|| "0x1") * 2 + 35) when using TestRPC (chainId will be something like
1504787153407 unless set using the --network-id option). So, the hex
value initially passed to Bytes.pad will have a length of 12 and on the
second pass a length of 15. The infinite loop is then entered because the
condition inside Bytes.pad will never be true (hex.length === 4):

const pad = (l,hex) => hex.length === l*2+2 ? hex : pad(l,"0x"+"0"+hex.slice(2));

If I change l to be 16 the function will return successfully. However,
I'm not sure if this is the correct solution/what side effects this may
cause as I do not have enough understanding of the web3.js library.

On a side note, this calculation of v will cause users of TestRPC to
encounter this bug https://github.com/ethereumjs/testrpc/issues/297.
Running TestRPC with a custom, small network ID should resolve this for now testrpc
--network-id 10.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ethereum/web3.js/issues/932#issuecomment-327787434,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ATQ3yMQqCOA5Pca-S7PyOQoqe--evP9Cks5sf-SqgaJpZM4OgFHv
.

sirlojik picture sirlojik on 28 Sep 2017

Have the same issue on a private network.
networkId == 1110011

mikeifomin picture mikeifomin on 6 Oct 2017

We will look into this. Thanks for brining it up.

frozeman picture frozeman on 6 Oct 2017
👍3

@frozeman I'm looking forward!
I think this issue is slowing down not only my project!

mikeifomin picture mikeifomin on 9 Oct 2017

Please test this branch and let me know if it fixes it: https://github.com/ethereum/web3.js/pull/1111

frozeman picture frozeman on 13 Oct 2017
👍2

It did not work for me =( same stack trace

mikeifomin picture mikeifomin on 16 Oct 2017

@mikeifomin are you sure you used the branch installation?

frozeman picture frozeman on 16 Oct 2017

I'm sure. But here is the code
https://github.com/mikeifomin/web3_acc_test/blob/master/index.js

And a bit of stacktrace

    at pad (/Users/mike/Github/web3_acc_test/node_modules/web3/
packages/web3-eth-accounts/node_modules/eth-lib/lib/bytes.js:39
:43)
    at pad (/Users/mike/Github/web3_acc_test/node_modules/web3/
packages/web3-eth-accounts/node_modules/eth-lib/lib/bytes.js:39
:43)
mikeifomin picture mikeifomin on 17 Oct 2017

@mikeifomin I updated the eth-lib version to 0.2.5 please re-test.

frozeman picture frozeman on 17 Oct 2017
🎉2 👍1

@frozeman yay!
The error is gone!
Huge thanks and respect from me and everyone from my team!)

mikeifomin picture mikeifomin on 17 Oct 2017

Awesome, can you test receiving and sending test ether

frozeman picture frozeman on 17 Oct 2017

I have tested manually sendTransaction method on private network. Transaction committed successfully and getBalance method for receiver account return expected amount of ether. So in my case I confirm that the issue is gone.

Maybe you talking about integration test with testrpc package?

mikeifomin picture mikeifomin on 17 Oct 2017

currently we have only unit tests, if you want to add some testrpc integration tests, that would be awesome! :)

frozeman picture frozeman on 18 Oct 2017

Can you also test main net transactions?

frozeman picture frozeman on 18 Oct 2017

should now be fixed in beta.24

frozeman picture frozeman on 19 Oct 2017
Was this page helpful?
0 / 5 - 0 ratings

Related issues

gabmontes picture gabmontes  Â·  3Comments
praveengupta0895 picture praveengupta0895  Â·  3Comments
3sGgpQ8H picture 3sGgpQ8H  Â·  3Comments
oktapodia picture oktapodia  Â·  3Comments
mishell-trickster picture mishell-trickster  Â·  3Comments