raskul
|
|
March 05, 2014, 07:38:50 PM |
|
snipped...
I'm sure you like gloating, but if you're not interested in the Version coin, why do you keep posting? You've made your point, you don't like V, move on. Let the development team handle the issues and the community around V to support it. You said Best wishes to us on a previous post. people kept replying to me it's only polite to respond. best wishes, R
|
tips 1APp826DqjJBdsAeqpEstx6Q8hD4urac8a
|
|
|
bitkokos
|
|
March 05, 2014, 07:42:39 PM |
|
|
O_o
|
|
|
staycrypto (OP)
Member
Offline
Activity: 70
Merit: 10
Crypto Craftsman
|
|
March 05, 2014, 07:48:31 PM |
|
Pools need to update so the network gets moving again.
|
V: VFvZNht5YRuKbENkbu4nG74w2MyjPB6Qty VersionCoin.com /r/version @VersionCoin
|
|
|
ClutchThese
|
|
March 05, 2014, 07:50:39 PM |
|
Pools need to update so the network gets moving again. Zeuspool is doing this now.
|
Signature for Rent - PM if Interested
|
|
|
bitkokos
|
|
March 05, 2014, 07:50:52 PM |
|
Pools need to update so the network gets moving again. if a pool doesn't update a coin stays blocked for ever?
|
O_o
|
|
|
sunsofdust
|
|
March 05, 2014, 08:13:14 PM |
|
Pools need to update so the network gets moving again. I would say there is another problem here. I had 800 GH pointed at this solo mining and previous to block 19079 I was solving a block every 4 to 5 minutes. And now, nothing for several hours, humm?
|
|
|
|
bitkokos
|
|
March 05, 2014, 08:16:21 PM |
|
Pools need to update so the network gets moving again. I would say there is another problem here. I had 800 GH pointed at this solo mining and previous to block 19079 I was solving a block every 4 to 5 minutes. And now, nothing for several hours, humm? I think you should wait too, until pools update so everything will be able to move
|
O_o
|
|
|
sunsofdust
|
|
March 05, 2014, 08:19:27 PM |
|
Pools need to update so the network gets moving again. I would say there is another problem here. I had 800 GH pointed at this solo mining and previous to block 19079 I was solving a block every 4 to 5 minutes. And now, nothing for several hours, humm? I think you should wait too, until pools update so everything will be able to move Will see, but I doubt that will help. 800 GH/s is more than enough to solve 1 block in 4 hours with the current diff of 33001.40430142.
|
|
|
|
bitkokos
|
|
March 05, 2014, 08:25:45 PM |
|
Pools need to update so the network gets moving again. I would say there is another problem here. I had 800 GH pointed at this solo mining and previous to block 19079 I was solving a block every 4 to 5 minutes. And now, nothing for several hours, humm? I think you should wait too, until pools update so everything will be able to move Will see, but I doubt that will help. 800 GH/s is more than enough to solve 1 block in 4 hours with the current diff of 33001.40430142. that must be a problem with the whole network (including you) :-)
|
O_o
|
|
|
mindfox
|
|
March 05, 2014, 08:27:34 PM |
|
Will see, but I doubt that will help. 800 GH/s is more than enough to solve 1 block in 4 hours with the current diff of 33001.40430142.
I agree with sunofblast. He should be able to find blocks with his new client and the pools would have just rejected them. But he should be able to see the blocks Something else is going on. Here is where I think the problem lies: vMerkleTree: 2014-03-05 20:26:02 UTC generated 4.00 ProcessBlock: nHeight: 19080 Difficulty Retarget - Kimoto Gravity Well PastRateAdjustmentRatio = 0.947312 Before: 1b01fc5f 000000000001fc5f000000000000000000000000000000000000000000000000 After: 1b01fc6e 000000000001fc6e25d42259675afabe930023cdc349fc308be220510e44c81a ERROR: AddToBlockIndex() : Rejected by stake modifier checkpoint height=19080, modifier=0xfa8e81623ecb5f87 ERROR: AcceptBlock() : AddToBlockIndex failed ERROR: ProcessBlock() : AcceptBlock FAILED ERROR: BitcoinMiner : ProcessBlock, block not accepted
|
|
|
|
baddw
|
|
March 05, 2014, 08:30:41 PM |
|
Pools need to update so the network gets moving again. Why would you have hard-coded checkpoints that stop block generation? Is this issue going to come up again?
|
BTC/XCP 11596GYYq5WzVHoHTmYZg4RufxxzAGEGBX DRK XvFhRFQwvBAmFkaii6Kafmu6oXrH4dSkVF Eligius Payouts/CPPSRB Explained I am not associated with Eligius in any way. I just think that it is a good pool with a cool payment system
|
|
|
mindfox
|
|
March 05, 2014, 08:31:30 PM |
|
From source code (main.cpp) // Hard checkpoints of stake modifiers to ensure they are deterministic static std::map<int, unsigned int> mapStakeModifierCheckpoints = boost::assign::map_list_of ( 0, 0x0e00670bu ) ( 19080, 0xad4e4d29u ) ( 30583, 0xdc7bf136u ) ;
My guess is that 19080 should be another kind of block, but it's normal so it's not accepted.
|
|
|
|
mindfox
|
|
March 05, 2014, 08:33:36 PM |
|
Why would you have hard-coded checkpoints that stop block generation? Is this issue going to come up again?
This is not the issue, you got it wrong. All coins have checkpoints, so the wallet can check blocks that are reliable (to avoid hard forking). He did well to update the checkpoints. My previous post gives a heads-up to the developer what to check
|
|
|
|
baddw
|
|
March 05, 2014, 08:36:26 PM |
|
Why would you have hard-coded checkpoints that stop block generation? Is this issue going to come up again?
This is not the issue, you got it wrong. All coins have checkpoints, so the wallet can check blocks that are reliable (to avoid hard forking). He did well to update the checkpoints. My previous post gives a heads-up to the developer what to check But other coins don't stop block generation when they hit those checkpoints, requiring everybody to download new wallets/daemons in order for the blockchain to continue.
|
BTC/XCP 11596GYYq5WzVHoHTmYZg4RufxxzAGEGBX DRK XvFhRFQwvBAmFkaii6Kafmu6oXrH4dSkVF Eligius Payouts/CPPSRB Explained I am not associated with Eligius in any way. I just think that it is a good pool with a cool payment system
|
|
|
bitkokos
|
|
March 05, 2014, 08:40:23 PM |
|
Will see, but I doubt that will help. 800 GH/s is more than enough to solve 1 block in 4 hours with the current diff of 33001.40430142.
I agree with sunofblast. He should be able to find blocks with his new client and the pools would have just rejected them. But he should be able to see the blocks Something else is going on. Here is where I think the problem lies: vMerkleTree: 2014-03-05 20:26:02 UTC generated 4.00 ProcessBlock: nHeight: 19080 Difficulty Retarget - Kimoto Gravity Well PastRateAdjustmentRatio = 0.947312 Before: 1b01fc5f 000000000001fc5f000000000000000000000000000000000000000000000000 After: 1b01fc6e 000000000001fc6e25d42259675afabe930023cdc349fc308be220510e44c81a ERROR: AddToBlockIndex() : Rejected by stake modifier checkpoint height=19080, modifier=0xfa8e81623ecb5f87 ERROR: AcceptBlock() : AddToBlockIndex failed ERROR: ProcessBlock() : AcceptBlock FAILED ERROR: BitcoinMiner : ProcessBlock, block not accepted
he didn't say he doesn't see the blocks. he said he doesn't solve them.
|
O_o
|
|
|
mindfox
|
|
March 05, 2014, 08:41:28 PM |
|
But other coins don't stop block generation when they hit those checkpoints, requiring everybody to download new wallets/daemons in order for the blockchain to continue.
You still got it wrong. It's not the checkpoints that made it stop working. Even if it was due to that fact, the wallet should have start working since there are users (like zeuspool or other wallets) that have updated. We should be able to go beyond that, but we're not. The problem is elsewhere. Please let's give some space to the developer to fix this issue.
|
|
|
|
staycrypto (OP)
Member
Offline
Activity: 70
Merit: 10
Crypto Craftsman
|
|
March 05, 2014, 08:44:18 PM |
|
mindfox, thank you, I believe you have identified a root cause. I am turning around another patch now.
As far as checkpoints go, with a PPCoin based PoS coin, there are hard checkpoints with spacing that right now is 10 days. It usually won't stop the network in its tracks but you will get the annoying message until the dev updates the code. I will probably look at moving that out to something more manageable.
I also noticed that block 19080 is apparently quite a large block, probably because of all the transactions backing up into it.
I'm on it.
|
V: VFvZNht5YRuKbENkbu4nG74w2MyjPB6Qty VersionCoin.com /r/version @VersionCoin
|
|
|
mindfox
|
|
March 05, 2014, 08:47:10 PM |
|
I can't debug from where I am right now, but: main.cpp if (!ComputeNextStakeModifier(pindexNew->pprev, nStakeModifier, fGeneratedStakeModifier)) return error("AddToBlockIndex() : ComputeNextStakeModifier() failed"); pindexNew->SetStakeModifier(nStakeModifier, fGeneratedStakeModifier); pindexNew->nStakeModifierChecksum = GetStakeModifierChecksum(pindexNew); if (!CheckStakeModifierCheckpoints(pindexNew->nHeight, pindexNew->nStakeModifierChecksum)) return error("AddToBlockIndex() : Rejected by stake modifier checkpoint height=%d, modifier=0x%016"PRI64x, pindexNew->nHeight, nStakeModifier);
kernel.cpp bool CheckStakeModifierCheckpoints(int nHeight, unsigned int nStakeModifierChecksum) { if (fTestNet) return true; // Testnet has no checkpoints if (mapStakeModifierCheckpoints.count(nHeight)) return nStakeModifierChecksum == mapStakeModifierCheckpoints[nHeight]; return true; }
In other words: The stakehash produced by the mined block is not what it should be, erroring out the code. Didn't read again the code that generates that checksum, I'm doing it as I post this. I will continue to examine the code in order to help the developer and the coin.
|
|
|
|
bitkokos
|
|
March 05, 2014, 08:49:58 PM |
|
I can't debug from where I am right now, but: main.cpp if (!ComputeNextStakeModifier(pindexNew->pprev, nStakeModifier, fGeneratedStakeModifier)) return error("AddToBlockIndex() : ComputeNextStakeModifier() failed"); pindexNew->SetStakeModifier(nStakeModifier, fGeneratedStakeModifier); pindexNew->nStakeModifierChecksum = GetStakeModifierChecksum(pindexNew); if (!CheckStakeModifierCheckpoints(pindexNew->nHeight, pindexNew->nStakeModifierChecksum)) return error("AddToBlockIndex() : Rejected by stake modifier checkpoint height=%d, modifier=0x%016"PRI64x, pindexNew->nHeight, nStakeModifier);
kernel.cpp bool CheckStakeModifierCheckpoints(int nHeight, unsigned int nStakeModifierChecksum) { if (fTestNet) return true; // Testnet has no checkpoints if (mapStakeModifierCheckpoints.count(nHeight)) return nStakeModifierChecksum == mapStakeModifierCheckpoints[nHeight]; return true; }
In other words: The stakehash produced by the mined block is not what it should be, erroring out the code. Didn't read again the code that generates that checksum, I'm doing it as I post this. I will continue to examine the code in order to help the developer and the coin. and the community :-)
|
O_o
|
|
|
mindfox
|
|
March 05, 2014, 08:57:55 PM |
|
and the community :-)
That goes without saying. I was just typing fast in order to get back to the code. I apologize if my post didn't look good.
|
|
|
|
|