How to know user deposit coins if exchange's coin daemon server is down?

[wsxdrfv]

So scenario is, if some of exchange's user deposit coin to his address given by the exchange, but at that time that exchange's coin daemon server was down,

then how exchange know later those missing transactions and record all of them to own record DB?

manually type [ coind listtransactions ] and compare manually?

Aren't there more automatic handling way of this sort of problem?

[1713399771]

1713399771

[1713399771]

1713399771

[mocacinno]

So scenario is, if some of exchange's user deposit coin to his address given by the exchange, but at that time that exchange's coin daemon server was down,

then how exchange know later those missing transactions and record all of them to own record DB?

manually type [ coind listtransactions ] and compare manually?

Aren't there more automatic handling way of this sort of problem?

most coin daemons have a json-rpc interface, i doubt anything happens manually... I think that exchanges will probably automise the process, or even just use the json-rpc interface of the daemon whenever you want to view your balances? The daemon can also use a hook to call a binary whenever a block contains a transaction that funds an address managed by their wallet, it doesn't matter if the daemon was down, upon syncing it'll just keep calling the hook everytime an incoming tx is found in a block.

Offcourse, there is no way of telling how an exchange works internally... Do they keep a seperate relational database with user's deposit/withdrawal records, do they run customised daemons,...

[MadGamer]

They clearly have ways to handle this otherwise exchanges wouldn't have any users by now.

What gave you the idea they they should type the command manually? It's very likely that they have built other tools for making this process automatic, something that try to run bitcoind after it crashed or something and then run that command.

[bob123]

This scenario sounds like it happend to you?
Together with the countless threads regarding basics of setting up an online service, this would definitely make sense.

If your system is broken, freely explain your issues and enough people would be willing to help you. Obfuscating your story won't help you to fix your problem and will cost anyones time who is going to come up with a detailed explanation.


If you, on the other hand, just asks because of curiosity, the answer depends on each exchange. Most probably have implemented their own error handling.
They either start rescanning from the point of failure, or have a different form of acquiring the information.

[cr1776]

The exchange would know because their server is monitoring the block chain.  Whether the block was generated after they restarted or hours before, they are monitoring each block as it arrives at their server and they know how far they have tracked.

So, server restarts.  It sees that it has tracked all the transactions in the block chain up to block X.  Block X+1 arrives from peers, process that block just as if we'd been connected all the time - after all, it could have JUST been mined or mined hours ago, it doesn't matter.  Block X+2 arrives do the same.  Block X+3 arrives, etc. 

Whether they get blocks X+1, X+2, X+3 in 10 seconds or 60 minutes doesn't matter, they are doing the same thing: processing blocks as they arrive.

So scenario is, if some of exchange's user deposit coin to his address given by the exchange, but at that time that exchange's coin daemon server was down,

then how exchange know later those missing transactions and record all of them to own record DB?

manually type [ coind listtransactions ] and compare manually?

Aren't there more automatic handling way of this sort of problem?

[wsxdrfv]

The exchange would know because their server is monitoring the block chain.  Whether the block was generated after they restarted or hours before, they are monitoring each block as it arrives at their server and they know how far they have tracked.

So, server restarts.  It sees that it has tracked all the transactions in the block chain up to block X.  Block X+1 arrives from peers, process that block just as if we'd been connected all the time - after all, it could have JUST been mined or mined hours ago, it doesn't matter.  Block X+2 arrives do the same.  Block X+3 arrives, etc.  

Whether they get blocks X+1, X+2, X+3 in 10 seconds or 60 minutes doesn't matter, they are doing the same thing: processing blocks as they arrive.

How monitoring the block chain? Are there way that is not performed via walletnotify or blocknotify option at coind's .conf file?

And what if that monitoring server is down?

[mocacinno]

The exchange would know because their server is monitoring the block chain.  Whether the block was generated after they restarted or hours before, they are monitoring each block as it arrives at their server and they know how far they have tracked.

So, server restarts.  It sees that it has tracked all the transactions in the block chain up to block X.  Block X+1 arrives from peers, process that block just as if we'd been connected all the time - after all, it could have JUST been mined or mined hours ago, it doesn't matter.  Block X+2 arrives do the same.  Block X+3 arrives, etc.  

Whether they get blocks X+1, X+2, X+3 in 10 seconds or 60 minutes doesn't matter, they are doing the same thing: processing blocks as they arrive.

How monitoring the block chain? Are there way that is not performed via walletnotify or blocknotify option at coind's .conf file?

And what if that monitoring server is down?

Like cr1776 said: it doesn't matter if your node is down. As soon as it's online again, it'll receive the blocks that were mined during the downtime and it'll treat them as if they were mined seconds ago... This includes using the walletnotify or blocknotify option.

[audaciousbeing]

So scenario is, if some of exchange's user deposit coin to his address given by the exchange, but at that time that exchange's coin daemon server was down,

then how exchange know later those missing transactions and record all of them to own record DB?

manually type [ coind listtransactions ] and compare manually?

Aren't there more automatic handling way of this sort of problem?

People who run the business knows the way they go about it and that is one of the uniqueness of blockchain. Unlike bank transactions that can be intercepted along the line that there is a conflict between the sender and the receiver with one claiming to have sent while the other claiming he has not seen. So far you copied the right address from their website, when they are through with their synchronization, it will definitely be there. I have sent to exchange sites without even knowing they had issues with their own wallet whereas from what I was checking, I was seeing several confirmations which was not showing and I was not disturbed because I knew I copied the right address from their site which later updated hours later.

If you are looking for operate an exchange, I am sure this would have been included in the software configured for the site and there would surely be a way to navigate around such scenario.

[buwaytress]

Yeah, as audacious points out, you're interacting with the blockchain at the end of the day - even when depositing Bitcoin into a centralised exchange. Their servers being down simply means your front end is not interacting with their back end. So account details-wise, you won't see an update until the connection is restored.

The Bitcoin network itself, however, continues to record your tx and confirmation. Once the exchange restores and syncs its wallet with Bitcoin network, they shouldn't have a problem updating details on your end. I've seen it often enough, where network shows many more confirmations than an exchange does. That lag's unavoidable.

Of course, if the service somehow ends up corrupting their wallet and database so badly they can't recover their wallets or can't correctly associate addresses to user accounts, then you're in trouble. One of the many, many risk scenarios of trusting a centralised service with your funds.