New Datacoin (DTC) pool for GPU!

[MarcusDe]

Can you do somethink with disconnecting nodes?

Actually I did.

Max connections from standard 8 is increased to 200 ;-)
There is xpm pool working on very same code (nobody mines there lol), connection number there is getting 100+ in few minutes, in DTC network after few hours max is 20-30.
And even then it looks that something tells network after long time 'your blocks are bad'.
I've run DTC wallets on other machines, they synchro when pool finds blocks.
I don't know what more I can do yet.

[Robin37s]

so dtc is officially dead now？

[MarcusDe]

so dtc is officially dead now？

I hope not, but when I had max 30 nodes connected EVER, what can you think...
I wonder where the rest of coputing power is, diff isn't dropping.

[Robin37s]

so dtc is officially dead now？

I hope not, but when I had max 30 nodes connected EVER, what can you think...
I wonder where the rest of coputing power is, diff isn't dropping.

oocook5u disappeared for a long time and i used to think that he is still in the corner.

[hashfun]

Data coin is Disable Deposit in Main Exchange bter.com  i dont know the deposit of dtc is temp or permanent

so if this happend , this coin wil die soon, if the dev not active.

[sampei7777]

[cut]
If we had block explorer....

Here is the first Datacoin block explorer

Also see what Bytestamp is:

[ANN] ByteSt@mp - The Internet Timestamp Service [DATACOIN]

[wayla]

dtc.graymines.net ID 493798
2014-09-14 19:18:54    c0f3bba24394a5dc68d68f884df4fa54d255e2a44d0d6207aad39cb7e1ccc54e    493798    158    10.68    DSAdJugFxKsgyPZMALQpK7Y7MYZkHdQe7i

dtc block explorer
height    493798
hash    17ba155bc8b211a17b69991fc85848244334ca526434f284b0f5333cf1818b34
headerhash    c8c42ec80aca456604709eb614e09b1e84428073f7c84dc50d82fdec59de1b26
merkleroot    6a2fc3b55d0db654355b4afa26c59045ec6df7b7454fcc3d5d82d18f4500a0aa
time    2014-09-14 09:30:37 UTC

the same ID ,but not the same time not the same hash,why?

[wayla]

MarcusDe your pool time different from  explorer,  maybe your need reindex again.

[wayla]

check the log file as below:

SetBestChain: new best=ecff65f85c928c69cece566ac0ebc0e17692324b97493ffc612c9e61e91979ee  height=495003  difficulty=9.680417 log2Work=24.552808  log2ChainWork=43.418368  tx=601003  date=2014-09-15 12:38:46 progress=0.999971

SetBestChain: new best=b77c642ef86929d0e5b983855937e3b65d088802e2227fd80e52517a3b7b1191  height=495003  difficulty=9.7036535 log2Work=24.651379  log2ChainWork=43.418374  tx=601002  date=2014-09-15 06:06:25 progress=0.972348


2014-09-15 13:30:04    26074bf60212ce71f4f53ba810abcfcaf10a5d63dcc511ff3ce749137c6ee067    495425    10    10.61    DEHoTUEbm4ZixpLcuC85Q6i3J16VSRf9rL
2014-09-15 12:06:10    74e9ee90eef9f8bfa64cd97e5eb9482e66cce6c686d78bebb7753535aa9618d8    495000    4    10.65    DEHoTUEbm4ZixpLcuC85Q6i3J16VSRf9rL

so don't mine dtc and let it die.

[MarcusDe]

OK, really WTF? We have http://www.bytestamp.net/blocks/index block explorer, right?

Look at those 2 images:
 http://graymines.net/upload/dtc-be_494986a.png before
http://graymines.net/upload/dtc-be_494986b.png after
 some time, when good blocks on pool changed on bad blocks.
Even in block explorer blocks change.


1st I've checked when I saw info there is block explorer, left page opened few hours when I was busy in work,
now I checked same blocks again.... hashes differ. Even in block explorer hashes changed. Really? LOL.
 
How my pool can trust ANY blockchain source?
How any miner can mine if ANY time blockchain can change without any known reason?

[MarcusDe]

MarcusDe your pool time different from  explorer,  maybe your need reindex again.

Pool time is okay, look at block explorer and pool (from log)

proof-of-work found
  target: 09.b3daa9
  multiplier: 36063e9d374c72000
  CBlock(hash=5a8e599cb51466458ff2b329378c0d5fed102c0ad9f53f965001938ce146da29, hashBlockHeader=cc376b457064e0990995f708db5d66392540d9bdb923ba37d24ec5c674d62b94, ver=2, hashPrevBlock=090ac327936472b2be9edcc9cf97b4b53bca17ddf798db1a91765aa935e60e61, hashMerkleRoot=e05b63995191f3edcd6e421e262bad8341b7819ff6b786262c4883c75922d302, nTime=1410790303, nBits=09b3daa9, nNonce=438623566, vtx=1)
  CTransaction(hash=e05b63995191f3edcd6e421e262bad8341b7819ff6b786262c4883c75922d302, ver=1, vin.size=1, vout.size=1, nLockTime=0, data.size=0)
    CTxIn(COutPoint(0000000000000000000000000000000000000000000000000000000000000000, 4294967295), coinbase 036d8f07010100062f503253482f)
    CTxOut(nValue=10.61000000, scriptPubKey=025765d30169e0ef87e8cd88d619e3)
  vMerkleTree: e05b63995191f3edcd6e421e262bad8341b7819ff6b786262c4883c75922d302
generated 10.61
keypool keep 5400
AddToWallet e05b63995191f3edcd6e421e262bad8341b7819ff6b786262c4883c75922d302  new
Committing 1 changed transactions to coin database...
SetBestChain: new best=5a8e599cb51466458ff2b329378c0d5fed102c0ad9f53f965001938ce146da29  height=495469  difficulty=9.7025552 log2Work=24.646566  log2ChainWork=43.419875  tx=601469  date=2014-09-15 14:11:43 progress=0.999908
NotifyNewBlock(495469)
ProcessBlock: ACCEPTED
keypool reserve 5401
received getdata for: block 5a8e599cb51466458ff2b329378c0d5fed102c0ad9f53f965001938ce146da29
received getdata for: block 5a8e599cb51466458ff2b329378c0d5fed102c0ad9f53f965001938ce146da29
received getdata for: block 5a8e599cb51466458ff2b329378c0d5fed102c0ad9f53f965001938ce146da29
received getdata for: block 5a8e599cb51466458ff2b329378c0d5fed102c0ad9f53f965001938ce146da29
received getdata for: block 5a8e599cb51466458ff2b329378c0d5fed102c0ad9f53f965001938ce146da29
received getdata for: block 5a8e599cb51466458ff2b329378c0d5fed102c0ad9f53f965001938ce146da29
received getdata for: block 5a8e599cb51466458ff2b329378c0d5fed102c0ad9f53f965001938ce146da29
received getdata for: block 5a8e599cb51466458ff2b329378c0d5fed102c0ad9f53f965001938ce146da29
received getdata for: block 5a8e599cb51466458ff2b329378c0d5fed102c0ad9f53f965001938ce146da29
received getdata for: block 5a8e599cb51466458ff2b329378c0d5fed102c0ad9f53f965001938ce146da29
received getdata for: block 5a8e599cb51466458ff2b329378c0d5fed102c0ad9f53f965001938ce146da29
received getdata for: block 5a8e599cb51466458ff2b329378c0d5fed102c0ad9f53f965001938ce146da29
received getdata for: block 5a8e599cb51466458ff2b329378c0d5fed102c0ad9f53f965001938ce146da29
received getdata for: block 5a8e599cb51466458ff2b329378c0d5fed102c0ad9f53f965001938ce146da29
received getdata for: block 5a8e599cb51466458ff2b329378c0d5fed102c0ad9f53f965001938ce146da29
received getdata for: block 5a8e599cb51466458ff2b329378c0d5fed102c0ad9f53f965001938ce146da29
received getdata for: block 5a8e599cb51466458ff2b329378c0d5fed102c0ad9f53f965001938ce146da29

[sampei7777]

OK, really WTF? We have http://www.bytestamp.net/blocks/index block explorer, right?

Look at those 2 images:
 http://graymines.net/upload/dtc-be_494986a.png before
http://graymines.net/upload/dtc-be_494986b.png after
 some time, when good blocks on pool changed on bad blocks.
Even in block explorer blocks change.


1st I've checked when I saw info there is block explorer, left page opened few hours when I was busy in work,
now I checked same blocks again.... hashes differ. Even in block explorer hashes changed. Really? LOL.
 
How my pool can trust ANY blockchain source?
How any miner can mine if ANY time blockchain can change without any known reason?

Because the blockchain source is the same.

I have in my datacoin.conf:

Code:

addnode = <IP address of graymines.net>

Now I removed it.

Let's wait few days and see what happens.

Thank you.

[wayla]

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

[vpn01]

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
[/quote   your wallet can synchronization??

[wayla]

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
[/quote   your wallet can synchronization??

yes, delete peer.dat and delete  addnode in datacoin.conf file ,then reindex again

[MarcusDe]

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
[/quote   your wallet can synchronization??

yes, delete peer.dat and delete  addnode in datacoin.conf file ,then reindex again

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? -.-

[sampei7777]

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
[/quote   your wallet can synchronization??

yes, delete peer.dat and delete  addnode in datacoin.conf file ,then reindex again

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.

 

[MarcusDe]

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
[/quote   your wallet can synchronization??

yes, delete peer.dat and delete  addnode in datacoin.conf file ,then reindex again

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 from 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?

[rots]

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
[/quote   your wallet can synchronization??

yes, delete peer.dat and delete  addnode in datacoin.conf file ,then reindex again

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 from 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?

This coin is died. Someone is fucking network, I think I already know how to do it. But why this bullshit do so, main exchange site bter will stop trading DTC soon, all people can't get profit then.

[sampei7777]

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??  

yes, delete peer.dat and delete  addnode in datacoin.conf file ,then reindex again

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.