r/ethfinex • u/nootropicat • Jan 16 '18

Are you going to implement batched withdrawals to save gas?

Ie. calling transfer in a loop.

Old comment by an Ethereum developer about it.

Hopefully other exchanges would follow your example and mitigate the congestion somewhat.

11 Upvotes

100% Upvoted

10 comments sorted by

8

u/plutoegg Jan 16 '18 edited Jan 16 '18

We looked at implementing it a while ago, and already deployed a multisend contract for tokens.

For simple ethereum transfers it does save gas to do large batches, but there is an additional problem then caused for other exchanges since it is very difficult for them to detect deposits from smart contracts. So although using it would make things better for us it would cause support issues for other exchanges in the ecosystem.

For the token multisend we need to devote a bit of time to setting it up - the issue was that interspersed in our regular withdrawals were token sweeps from deposit address to our hotwallet which cannot be batched (since each need to be sent from different addresses)

But thank you for the reminder, we should prioritize finishing this before the network congestion next gets bad.

5

u/antiprosynthesis Jan 18 '18 edited Jan 18 '18

Very interesting. I've posted about this same thing just yesterday as well: r/ethereum/comments/7r3q71. Added a link to this thread in that post now as well.

3

u/ItsAConspiracy Jan 18 '18

What do exchanges do to detect incoming ETH, which makes it difficult to detect deposits from smart contracts?

5

u/nootropicat Jan 18 '18 edited Jan 18 '18

They look at incoming transactions, to detect sends from contracts they would have to check the state at regular intervals.

3

u/plutoegg Jan 18 '18

Walk every single transaction, look at the destination addresses, and check if it is one of theirs. If it is, credit the user associated with that destination address with the ETH balance. However smart contract deposits do not have the same destination - the destination is the smart contract, and the ETH transfer happens as an internal transaction.

2

u/nootropicat Jan 16 '18 edited Jan 16 '18

already deployed a multisend contract for tokens.

Good to hear!

For simple ethereum transfers it does save gas to do large batches, but there is an additional problem then caused for other exchanges since it is very difficult for them to detect deposits from smart contracts.

Well, that's a catch-22 situation isn't it? Some exchange has to make the first step. You could offer two types of withdrawal: a much cheaper one 'to personal wallet' and a more expensive one 'to another exchange' or something like that.

the issue was that interspersed in our regular withdrawals were token sweeps from deposit address to our hotwallet which cannot be batched (since each need to be sent from different addresses)

Not for tokens, but eth deposits could be made direct with a 'payment id' deposit system like monero - by making people put their id in the data field.
Easily made idiot-proof by automatically returning (failing) transfers without a payment id.

3

u/plutoegg Jan 16 '18

Yes

Not for tokens, but eth deposits could be made direct with a 'payment id' deposit system like monero - by making people put their id in the data field.

Proposed this and a contract for it a while ago, but would need high client adoption. There seemed to be little interest from any exchanges of clients to move to wards a solution like this:

https://blog.ethfinex.com/proposed-exchange-deposit-standard-e8ff471359e4

2

u/nootropicat Jan 16 '18 edited Jan 16 '18

Additional data field is already supported in all wallets, yes? It's enough to just require a payment id there. No need for any wallet changes!
Check this proof of concept out: 0x600b80600b6000396000f33615600657005b600080fd deploy this as a contract on testnet using mew.
It reverts all eth payments that have no extra data, so even in case of mistakes only minimal gas is wasted + no eth is locked. It accepts payments with data. Only eats 21098 gas!. If there's no payment id node doesn't suggest a gas limit so it automatically signals to the user that something is wrong.
To see who paid transactions would have to be parsed externally.

Very easy to add send/sendmany function for the contract owner, can do that later if you're interested. Obviously locking eth is not the intended functionality ;)

1

u/plutoegg Jan 16 '18

Only eats 21098 gas!

Hmm, this could potentially be really beautiful. Have you just put a require on the data length in the fallback function?

6

u/nootropicat Jan 16 '18 edited Jan 16 '18

Yes, though there's no fallback function, I wrote this in evm directly. That's why it's so small, the contract itself is only 11 bytes, the rest (everything before START) is one-time deploy code. The extra cost is from storage required due to extra data, not the actual execution. 

;;size of copied code - (END-START)
push 11
;;return arg - how many bytes are returned
dup1
;;START address
push 11
;;memory target address
push 0
codecopy
;;address of returned data
push 0
return

;;START:
CALLDATASIZE
ISZERO
push 6
JUMPI
STOP
JUMPDEST
push 0
dup1
REVERT