Is there not a hybrid option that could solve this?.. It seems a rather sticky problem atm… suggesting a service is not available for a period of time is not a feature. Also, will that time increase if block size or numbers of transactions rise??
Normally blocks “come in” at a rate 1MB/10 min, so when there’s a reorg couple of blocks suddenly get announced out of blue. It takes time on Bitcoin Core, but then on counterparty server you have to rescan all those transactions and you’re basically 30 mins behind (with 3 blocks) to begin with, and new data keeps coming.
One approach is faster rescanning, another is to potentially make improvements on the DB side which is complicated and needs work. Until the 2nd option is available, the only other approach is to use fast systems to rescan quickly, which is what Coindaddy does well.
With larger block sizes, I think this could be more pronounced, but then maybe there would fewer reorgs, we don’t know. But by then the 2nd approach could be ready (guys from Tokenly may give it a try), so overall we’ll probably not see deterioration.
Could you tell us how long we must wait on the first launching counterparty-server?
I see it will depends on the machine spec running counterparty-server.
So roughly scale on 2 core / 4GB RAM / HDD.
a few days, a couple of weeks, or a month?
Depends on the speed of your machine, of course, but there’s a “bootstrap” command that can download a recent copy of CP DB for you.
That can cut down the wait time to 10 mins.