1

I am reading an interesting honeypot posted years ago. But I was confused by how the honeypot contract is implemented. More specifically, take this transaction as an example. As we can see, during this transaction:

TRANSFER  1 Ether From 0x6f49baef279f8c40d7479f5be6a9bbf5fc607af0 To  0x95d34980095380851902ccd9a1fb4c813c2cb639
TRANSFER  2 Ethers From 0x95d34980095380851902ccd9a1fb4c813c2cb639 To  0x6f49baef279f8c40d7479f5be6a9bbf5fc607af0

However, after the transaction, the balance of 0x95d34980095380851902ccd9a1fb4c813c2cb639 increased by 1 ether. It looks like the honeypot contract reverted half of the transaction.

There were discussions here.

I also tried revert() assert() in my TransferLog.AddMessage. But neither of them worked: the whole transaction reverted and no ether was sent to the contract.

Any hints/help will be appriciated.

2
  • As I see it here CONTRACT:0x6f49baef279f8c40d7479f5be6a9bbf5fc607af0 first tried to transfer 1ETH to 0x95d34980095380851902ccd9a1fb4c813c2cb639 and that went well. But then CONTRACT:0x6f49baef279f8c40d7479f5be6a9bbf5fc607af0 tried to send 2ETH to itself from the other account, and that ofcourse failed.
    – Sky
    Oct 20 at 9:50
  • I do not think so, that's how the honeypot contract works. Please see the contract solidity code for more: etherscan.io/address/… And here is a discussion: reddit.com/r/ethdev/comments/7x5rwr/…
    – Dongguo
    Oct 20 at 10:07
2

No, a transaction is fully atomic: either everything in it fails, or everything succeeds.

There are minor exceptions to this rule in the sense of try-catch statements, which allow the calling contract to allow the called external contract to revert, without reverting the calling contract as well. So in this case the called contract's state changes are reverted, but the caller contract continues executing (and the transaction as a whole may still succeed). More details about try-catch: https://blog.ethereum.org/2020/01/29/solidity-0.6-try-catch/

Looking at the transaction https://etherscan.io/tx/0xed5eaf959224dff10fb705e16af81017374f3f3856ada926571aa9f8ef8e0b63 , it would appear to go like this:

  1. 0xe0b4789d1cb42f0ee149bfbc12f016dbd55db33b sends 1 Eth to 0x6f49baef279f8c40d7479f5be6a9bbf5fc607af0 (during the function call)
  2. 0x6f49baef279f8c40d7479f5be6a9bbf5fc607af0 sends 1 Eth to 0x95d34980095380851902ccd9a1fb4c813c2cb639
  3. 0x95d34980095380851902ccd9a1fb4c813c2cb639 sends 1 Eth to 0x6f49baef279f8c40d7479f5be6a9bbf5fc607af0
  4. 0x95d34980095380851902ccd9a1fb4c813c2cb639 sends 1 Eth to 0x6f49baef279f8c40d7479f5be6a9bbf5fc607af0

With this logic, 0x6f49baef279f8c40d7479f5be6a9bbf5fc607af0 should end up with 2 Eth more. But if you look at the "State" tab, you notice that the situation is quite different.

This is probably some funny way how Etherscan displays some information. Or maybe there is even a bug in their logic. Just remember that Etherscan is an arbitrary third-party service, which is centralized and shouldn't be trusted blindly.

So, no, I don't understand how Etherscan's data should be read.

3
  • Thanks, that's how I understand it. Could you please take a look at the example transaction I posted(in the description). And see if you can find the trick/magic. [It does look like HALF of the transaction reverted]. If you read the contract source code, try/catch/low-level call is not the case.
    – Dongguo
    Oct 20 at 10:35
  • Edited to add more info Oct 20 at 10:52
  • I do not think it etherscan's problem. Not just etherscan, if you read the tx from other 3rd party services, it is the same. Example: tx.blocksecteam.com You can read the "Account Balance" on it.
    – Dongguo
    Oct 20 at 11:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.