Closed darren closed 4 years ago
This is an interesting situation. Function signatures are defined by the first four bytes of their signature hash, and due to the number of signatures out there we are starting to see clashes. In this case, the transfer()
function signature is being overwritten by something else, and because the arguments don't match it's struggling. I'm going to tweak the way that ethereal takes signatures from the directory by going in age order, so that a newer signature doesn't overwrite an older (and most likely more popular/supported) signature.
Ethereal version 2.3.8 should fix this:
$ ethereal version
2.3.8
$ ethereal transaction info --transaction=0x8c6bf43be0d649d06d7cab5aec6c96ca1e1e53e09fb41d726a997c41a0b9ae5f --verbose
Type: Mined transaction
Result: Succeeded
Block: 10106518
From: 0x00D7e5eE00549EFd5E1228D98B32706555F664f7
To: 0xdAC17F958D2ee523a2206206994597C13D831ec7
Nonce: 11410
Gas limit: 240000
Gas used: 41209
Gas price: 125 GWei
Value: 0
Data: transfer(0xA9f5B14b46A59BE0be5a547AE240C4804fB1602F,200455082)
Logs:
0:
From: 0xdAC17F958D2ee523a2206206994597C13D831ec7
Event: Transfer(0x00D7e5eE00549EFd5E1228D98B32706555F664f7,0xA9f5B14b46A59BE0be5a547AE240C4804fB1602F,200455082)
After examination it appears that some unknown people decided to infect the 4byte directory with suspicious function names that just happened to have the same signature as common ones, including all of the ERC-20 functions. I've added a blacklist function to exclude these from the list of acceptable functions.
Thank you for reporting this; if you meet any further problems please open a new issue.
ethereal version 2.3.7