496188 4d2d9805c025187b2c7b49008f22b0b349d0c1d2696ef2282d476a167f9be3b5 1 2014-09-16 01:05:56 UTC
496187 809e51f285a03d41d3d92738d7cb063f5082d0a28a285d706f993f14251e9e03 2 2014-09-16 01:10:42 UTC
496186 24a02e744d5e02d85590e654dc0891957af7cf756b5dd0f458931538c3e9daa9 3 2014-09-16 01:10:38 UTC
496185 bd0af56085b3d186f31d440cc3dad40759ef54c3828c4a2a815f4dc7e3c10638 4 2014-09-16 01:10:14 UTC
496184 c502c60379e4f268a517dd2c537481e8ca60522d1eb04b35d5ee34a47f308317 5 2014-09-16 01:10:20 UTC
496183 64c231025fbffbc76878c33d08802564d913584bafa16f5d50e22e6610ea74a1 6 2014-09-16 01:09:26 UTC
496182 71270e18282442132dfed73f8b86e4c33d25e3332685b37a1f55693f4ce72bd0 7 2014-09-16 01:09:08 UTC
496181 68ee83eca30dd5891cbd61e44b65cd795db4e719b1d0d5517a446e17571fe256 8 2014-09-16 01:08:11 UTC
496180 b0456f9be6bd2f9fadba33af922e8a5db184ccfbd008cd69ffddf8bc5e2fc3b8 9 2014-09-16 01:06:55 UTC
496179 9705d7bef0a0d2e9288da1fe4fee10173ccffb507c6f1f09f130089daad9de7a 10 2014-09-16 01:05:55 UTC
179-187 utc time large then 188, maybe some pool link to some shit node or peer
your wallet can synchronization?? 496187 809e51f285a03d41d3d92738d7cb063f5082d0a28a285d706f993f14251e9e03 2 2014-09-16 01:10:42 UTC
496186 24a02e744d5e02d85590e654dc0891957af7cf756b5dd0f458931538c3e9daa9 3 2014-09-16 01:10:38 UTC
496185 bd0af56085b3d186f31d440cc3dad40759ef54c3828c4a2a815f4dc7e3c10638 4 2014-09-16 01:10:14 UTC
496184 c502c60379e4f268a517dd2c537481e8ca60522d1eb04b35d5ee34a47f308317 5 2014-09-16 01:10:20 UTC
496183 64c231025fbffbc76878c33d08802564d913584bafa16f5d50e22e6610ea74a1 6 2014-09-16 01:09:26 UTC
496182 71270e18282442132dfed73f8b86e4c33d25e3332685b37a1f55693f4ce72bd0 7 2014-09-16 01:09:08 UTC
496181 68ee83eca30dd5891cbd61e44b65cd795db4e719b1d0d5517a446e17571fe256 8 2014-09-16 01:08:11 UTC
496180 b0456f9be6bd2f9fadba33af922e8a5db184ccfbd008cd69ffddf8bc5e2fc3b8 9 2014-09-16 01:06:55 UTC
496179 9705d7bef0a0d2e9288da1fe4fee10173ccffb507c6f1f09f130089daad9de7a 10 2014-09-16 01:05:55 UTC
179-187 utc time large then 188, maybe some pool link to some shit node or peer
Did that few times.
Not even that, downloaded whole blockchain leaving only wallet and config without peers.dat.
Besides I had old pool under other IP, and I've set this pool clean of any nodes.
Besides, with 20-40 nodes connected all time how it can even happen? -.-
But...
Are you sure this is an error?
In Datacoin there are not huge mining pools, we only have several solo miners.
Now I think this happens:
1) miner A resolves block 496187 at 2014-09-16 01:01:00 UTC
2) miner A resolves block 496188 at 2014-09-16 01:05:56 UTC
3) miner B resolves block 496187 at 2014-09-16 01:10:42 UTC
4) miner B resolves block 496188 at 2014-09-16 01:17:42 UTC
5) miner A gets orphaned block 496187 while its block 496188 is good
6) miner B gets orphaned block 496188 while its block 496187 is good
Because I *think* that the time on the block is set when the block is resolved
BTW, I just did an update to Bytest@mp block explorer.
Now, when you click on block details, at the bottom there is the link "Block History".
This returns the block's contents for the first 10-12 confirmations
Of course it does not have data for older blocks.
Hope it helps.
I understand your point.
But...
Those are not 1-2 orphaned blocks, whose network correct in 5 minutes.
Those are series of 100+ blocks, they are marked orphans/non-existant after few hours, with 100+ confirmations.
If my miners find bad block, network correct it in short time, give correct blockchain, that would be great.
But they mine, mine and mine, and then oh, it was just waste of electricity.
That doesn't happen with 2-3 nodes connected, but with 20-30 or more. Its not connected with wooden modem, but with 1Gb/s symetrical transfer.
I can give you listing of all blocks mined by pool fromAre you runnin start if you want.
Next solid argument is that I've made fresh private pool from start (without adding main pool as node) connected single miner to it. Miner found block, that same block wasnt mined by main pool (pool saw it mined somewhere else). So... how could you explain that?
If there is 'bad node' somewhere, what about every other node?
The last orphan block is 496971.
Now if you see its history, I did never receive your hash (6c71aed003a5cd5eaa9cc5b0c0d24a206b8a8478beee0796a1b60ce758698358). So this block was orphan from beginning.
Let's wait until a block with lots of confirmations becomes orphan, then from its history on ByteSt@mp we can understand something else.
Btw, you already know the answer:
Things start to clean. When big Chinese mine connects we have synchro, then it disconnects, mines at faster rate than pool is, and when connects again, network takes higher block height and we loose blocks mined between.
If I have 2000 nodes in my private network and I mine having it disconnected from Internet, when I connect it to Internet you are on the shortest blockchain branch with only 30 nodes and you lose your blocks. Also block explorer moves on the longest blockchain branch.
Maybe this is the why Bter disabled DTC withdrawals.
And about the fresh private pool... could your main pool be the 'bad node'?
Because you say
Besides I had old pool under other IP, and I've set this pool clean of any nodes.
... I would wait if on this new pool happens that blocks with 100+ confirmations become orphan.
Because what is already happened (blocks 496187 and 496188) is a "normal" orphan block.
BTW, we need miners. A lot of miners. What about setting up also a CPU mining pool?
You could catch all ex miners of Gpool. So no more solo miners, and no more orphan blocks for you.
