search

almindor / etherwall

Ethereum QT5 Wallet
GNU General Public License v3.0
142 stars 59 forks source link

Difficulty sending ERC20 tokens #72

Closed vipercps closed 6 years ago

vipercps commented 6 years ago

Hi, I'm having trouble sending my BDCD Tokens to my myetherallet wallet. 01- I successfully added the token - BDCD 02 - I tried and gave an error - https://etherscan.io/tx/0xdce3913eb7c2925ad825c8ff6179e76e27d856445f8beb1fd26587962792e329 - I placed the address of my myetherwallet (0x856d02DE9e072339D005bf6D056375b79aD55B5B) but looking at the etherscan I saw that it emviu to another address (address of the contract) What am I doing wrong?

almindor commented 6 years ago

So the reason why it went to the contract is because token "sends" are actually calls to the token's Transfer method.

So the actual transaction is from your address to the token contract, telling it to transfer X amount of given token to destination address (which should be encoded inside the tx data).

When you tried sending, did you select BDCD in the token selector in the send transaction window?

This TX looks "wrong" it seems to have no data and it failed for some reason, tho I'm not sure what the reason was. I suspect since it didn't have any data (which is the method to call + params) it was rejected by the contract.

I'll try adding this token and see if there's something wrong.

almindor commented 6 years ago

Seems there's a conversion bug that pops up with the right combination of value and token decimals. Will try to push a fix ASAP.

In the meantime, if you need this sent ASAP and this is a normal address (not TREZOR), you can import it into myEtherWallet directly, just find the appropriate UTC--... file for it in the datadir. myEtherwallet allows importing geth accounts.

almindor commented 6 years ago

This issue is now fixed in master, will close when the release is ready (by tomorrow).

Please confirm if I can reimburse you for the failed TX gas cost of 0.0000447 Ether to the origin address 0x1B74aF06B5371832e87980E7dE6dad253B03cf95

The issue was a bad to-int mid-conversion of the token value. If the value was bigger than int can hold (in base units) it'd fail "silently" (there was an error in the log only).

I've fixed the conversion error and will also add a way to handle failures more visibly on the front-end so people won't try sending invalid transactions if anything else ever fails.

almindor commented 6 years ago

This should now be fixed in v2.1.2, please confirm if so or reopen if you still have issues.

Also please confirm the address for reimbursement of the transaction fees.