11

A Coinbase exchange engineer said:

"Depositing from smart contracts is hard. Smart contract outputs are not like normal ETH transactions and it is non-trivial for us to get notified when we receive coins from smart contracts."

Similarly, the Bitfinex exchange says:

"At this time Bitfinex does not support Ethereum transactions generated from smart contracts. To avoid missing deposits or deposit delays ETH should only be sent in traditional transactions. If you are uncertain that your deposit will not be sent as part of an Ethereum contract execution, please find out for sure before sending your deposit."

What is the technical difference between transactions generated by smart contracts and transactions generated by humans? Why is it harder to be notified when a coin is received from a smart contract (how would an exchange get notified when they receive coins from a human, and how would they get notified when they receive coins from a smart contract, and why is this different)? What was the motivation for this design choice by the Ethereum designers? Where can I go to read more details?

I skimmed https://github.com/ethereum/go-ethereum/wiki/Contracts-and-Transactions but did not see the answer there.

  • This is a good question, for me the problem was only due tu higher fees that could make a refund refused. But saying the output is different, I can't see the difference between a TX from an account and one from a contract. – Nicolas Massart May 24 '16 at 20:29
11

Here's an intuition. The simplest transaction in Ethereum costs 21000 gas and looks like this:

{from: '0x from', to: '0x to', value: web3.toWei(1, "ether")}

When you're depositing to the exchange, the exchange can watch for transactions that are sent to this deposit address. For example, for block 99 they could use web3.eth.getBlock(99, true, ...), and for each transaction object check if to equals the deposit address, and the value (amount of Ether in wei) that was sent. Relatively straightforward for the exchange to see what you've deposited.

But if you are using a contract to make a deposit, the to is no longer the deposit address that the exchange gave you. The to is the address of your contract, and in the transaction there will be an additional data field. This data provides instructions to the contract, to execute code, which may then transfer the Ether to the deposit address. The exchange has to also execute the code, if it wants to be sure that it received funds from such execution. (An exchange could use web3.eth.getBalance to monitor balances of deposit addresses, but if it wants to know exactly where the funds came from, it has to execute the code of all transactions.)

That's an overview and to read more, the Ethereum Wiki has links to other material such as the Yellow Paper, and White Paper. Reading this StackExchange for highly voted questions and answers, with tags like and is also helpful.

Technically, transactions are only initiated by humans: a contract invoking another contract is a message call (as defined in the Yellow Paper) not a transaction. Only the transaction is recorded on the blockchain because all further execution can be derived from the transaction.


For why withdrawing from an exchange to a contract wallet/account is not straightforward, it's because more gas is needed than the basic 21000 gas. Different contracts could consume different amounts of gas, and sufficient gas must be provided by the exchange otherwise the transaction does not take effect: the funds remain will remain with the exchange.

  • Sorry if I repeat what you wrote, but I need you to confirm that what I understood from your post is right. so once the ether is transferred from the contract to the account, you have to replay all from the initial transaction that called the contract to determine the final accounts balance because contracts don't have a state on the network, only transactions have one ? Is that right? – Nicolas Massart May 25 '16 at 7:16
  • 1
    @NicolasMassart Comment is a little unclear, but I try. Contracts do have state. But as an exchange, you have to replay or execute transactions to find out which contract deposited the funds. A contract could record which accounts it has paid, but as an exchange, you don't know which contracts do this and how to access the state of such a contract. There's userAccount->contract->possibly many other contracts->exchange deposit address. As the exchange, you only know about the very last item. – eth May 26 '16 at 5:50
  • I guess i still don't understand why an exchange would need to know where a deposit comes from. It seems to me that checking web3.eth.getBalance should be enough. Perhaps the computational cost of running web3.eth.getBalance once for each deposit address, every block, is greater than the computational cost of comparing each deposit address against each transaction? But why would that be? – bshanks May 27 '16 at 22:39
3

ETHEREUM HAS TWO METHODS OF SENDING FUNDS:

Normal Transaction: A piece of data, signed by an External Actor. It represents either a Message or a new Autonomous Object. Transactions are recorded into each block of the blockchain.

This means that a transaction represents either a Message or a new contract.

Internal transaction (message): Data (as a set of bytes) and Value (specified as Ether) that is passed between two Accounts, either through the deterministic operation of an Autonomous Object or the cryptographically secure signature of the Transaction

This means that an internal transaction is the data and amount of Ether that is passed between two accounts. An internal transaction is created by contracts interacting with each other, or by a transaction.

A contract is only capable of sending an internal transaction.

Some Exchange wallets are only capable of receiving normal transactions. DO NOT SEND funds from a smart contract to those. The exchange software that interacts with the wallet address will not pick up internal transactions.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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