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.
When you send a transaction, you will receive back a transaction hash.
Use the command getTransactionByHash({transaction hash}) to retrieve the transaction details. Your blockNumber should be non-null if the transaction has been mined and included into a block.
The call is documented in https://github.com/ethereum/wiki/wiki/JSON-RPC#eth_gettransactionbyhash with the following example:
// Request
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByHash","params":["0xb903239f8543d04b5dc1ba6579132b143087c68db1b2168786408fcbce568238"],"id":1}'
// Result
{
"id":1,
"jsonrpc":"2.0",
"result": {
"hash":"0xc6ef2fc5426d6ad6fd9e2a26abeab0aa2411b7ab17f30a99d3cb96aed1d1055b",
"nonce":"0x",
"blockHash": "0xbeab0aa2411b7ab17f30a99d3cb9c6ef2fc5426d6ad6fd9e2a26a6aed1d1055b",
"blockNumber": "0x15df", // 5599
"transactionIndex": "0x1", // 1
"from":"0x407d73d8a49eeb85d32cf465507dd71d507100c1",
"to":"0x85h43d8a49eeb85d32cf465507dd71d507100c1",
"value":"0x7f110" // 520464
"gas": "0x7f110" // 520464
"gasPrice":"0x09184e72a000",
"input":"0x603880600c6000396000f300603880600c6000396000f3603880600c6000396000f360",
}
}
Then call eth_blockNumber (https://github.com/ethereum/wiki/wiki/JSON-RPC#eth_blocknumber) to get the current block height. Your number of confirmations is the eth_blockNumber result minus the eth_getTransaction blockNumber result.
Best Answer
From George Hallam:
For reference, 12 confirmations is approximately 3 minutes.