How to handle ether deposits like exchanges do?

Question

One of the core philosophies of Ethereum is decentralization. However, there are still many valid use cases to provide centralized wallet services, exchanges being one of the most well known examples.

There seems to be very little information available how to technically implement deposits for such scenarios.

• What is the latest recommendation for the number of tx confirmations with the Homestead release? ¹
• Are there any libraries or services that provide sample implementations? ²
• What is the rough pseudo code implementation to handle this yourself?
• Any other considerations? ³

1) 5 confirmations mentioned here What number of confirmations is considered secure in Ethereum? and 12 here How should I handle blockchain forks in my DApp?, but how relevant these are still with the Homestead release?

2) reflux-tx is mentioned here How should I handle blockchain forks in my DApp?

3) I've seen Vitalik recommending running two nodes to reduce the risks.

Answer 1

You have asked a number of questions in addition to your main question which was how to handle ether deposits.

The main problem with what you are trying to grapple with is the double-spend issue. If someone deposits to your Dapp exchange how do you ensure that the funds are not double spent, and how do you deal with funds that are deposited and then effectively unspent due to a fork?

The answer is somewhat in your court as the DAPP Exchange developer - you decide. So why not choose 24 blocks or, as one exchange does, 360 blocks? Whichever gives you the confidence you need.

I realise this is not a technical answer, but there is a functional issue with this, mainly that the user who submits a buy or sell order will have to wait the same time for it to be completed or entered into the order book. So you are having to trade stability for usability.

You should also be aware that due to the nature of the block creation process, you will not be able to process orders quickly or in the same way as you would on a centralised service. This is because one node cannot be aware of all orders (meaning transactions) placed anywhere on the network at the same moment it is trying to process orders it has received via the network.

This again is a major difference with a centralised service, and you should consider this too as part of the same solution.

I am not aware of any libraries that are available that could provide a quick answer for you, but there appears to be a number of projects out there.

Answer 2

What is the latest recommendation for the number of tx confirmations with the Homestead release?

According to the web3 APIs, 12 blocks is good to make sure that there isn't a fork. As for tx confirmations...I'd say 5 is still the defacto amount you want in there. That is obviously going to change with Serenity, and I wouldn't be certain with how to answer that given the vast change Casper will be bringing along with it. Follow Vitalik's blog so you can keep these things in mind while you are developing.

Are there any libraries or services that provide sample implementations?

hmmm...you'd probably want to be working with events and that handling...not certain about your tx confirmation area...there doesn't appear to be any premade tools for those purposes...probably would have to hack something together in one of the clients (would recommend using Parity for this because you want something fast...and Parity is blazingly fast).

What is the rough pseudo code implementation to handle this yourself?

something like this

js:

var i = myEthereumEvents
myEthereumEvents.watchAllEvents() {
    if (eventHit)
         var boolean = contract.promisifiedCheckBalanceOfPeer()
         if (boolean)
              contract.exchangeTokenValue()
}

now you are probably going to need to collect interest on some of them and create some kind of load balance in Solidity...this will take some thinking on your part...there's tons of examples of metacoin creation on there, you would just have to get it set up to mimic the token supply of other chains? This might help secure in the amount necessary...on the other hand you may be talking about something completely different and want something purely from an exchange side...one thing I would recommend for certain is turning off fast sync and monitoring the amount of incoming transactions and adjust accordingly to your algorithms.

Let me know if this answers your question.