We are once again back with the next part of our series All About Smart Contract Bugs & Security – A cakewalk series, discussing with you a problem that is quite often faced by many crypto users, ether being lost in the transfer….so, where does it go? Let’s find out.
Do check out the other parts in the series wherein we talk about Race conditions, Delegate Call, Stack Size Limit, and many other bugs that prove fatal to your smart contracts.
Did you Lose your Ether while Transferring It?
Table of Contents
often at times, we hear people complaining about losing Ether while they were making a transaction or Ether not showing up in their wallet after a successful transfer, why does this happen?
When sending ether, the user has to specify the recipient address, which takes the form of a sequence of 160 bits. However, many of these addresses are orphan, i.e. they are not associated with any user or contract. If by chance, the user sends some ether to an orphan address, it is lost forever.
The above image represents a transaction in which the value=0 Ether even after a successful transfer was performed by the user. Sending Ether to such an orphan address might have negative impacts on the overall system as money is effectively lost.
There is almost no way yet to predict whether an address is orphan or not. And since the lost ether cannot be recovered, it becomes essential for programmers to manually ensure the correctness of the recipient addresses.
More on Orphan Addresses/Blocks…
Orphan blocks often referred to as stale blocks, are blocks that are not accepted into the blockchain network due to a time lag in the acceptance of the block in question as compared to the other qualifying block. Orphan blocks are valid and verified but do not make it to the chain. They are also known as detached blocks as they exist in isolation from the network.
These stale blocks are initially added to the blockchain network but are removed once a better chain is found. However this time lag is enough for a user to send their Ether to this orphan block, losing it forever.
How to Avoid such Scenarios?
Let us consider a real-life scenario where the user has signed three transactions with nonces 10, 11 and 12. Also assume that they were mined at blocks A, B and C. A chain reorg can occur at block C, with the new blocks being B’, C’ and D’. Any transactions occurring in blocks B and C that do not appear in the newer blocks B’, C’ and D’ should not be considered as mined. In theory, transactions 11 and 12 will be again in the pending pool and miners can add them to subsequent blocks.
However, in practice pending pool size is limited and the transaction will be discarded at some point. User should inspect the pending pool and re-send them if they have disappeared.
How Much to Wait Before Sending Ether Again?
The wait time depends on the particular operation and network congestion. If there’s a hurry perhaps increasing the gas price will help but the user will have to sign new transactions, if not then we suggest the user could try every hour until the network accept them.
This is ImmuneBytes take on what happens when Ether is lost in transfer along with a real-life example to show you how it works and hampers your transactions. We hope this helps you in avoiding such mistakes while processing a transaction. Connect with our team to get your smart contract free of any vulnerabilities and loopholes such as this one.
Tune in next Thursday for Part-X of this series wherein we discuss Uninitialized Storage Parameters in smart contracts.