|
When did I say I would stop primecoin development? Go back to the prerelease annoucement, I specifically said both ppcoin and primecoin would have dedicated long term support.
Yes primecoin is part of my long term strategy to compete better, since when is having a strategy a bad thing? So please don't listen to someone who'd like to twist my words to suit his own agenda.
|
|
|
|
|
I notice some users releasing builds with changes to protocol related code without my review. This is dangerous. If you want to optimize that aggressively you should be working on an external miner instead.
Please remove any optimization code touching protocol related functions such as Target* functions, CheckProofOfWork(), ProbablePrimeChainTest() etc.
|
|
|
|
stuck at 2 blocks synced no matter how many connections i have
received block 9657908608eeddce30390a30ac72b3348fd584c1b3cb917922707f9cfc01a488
SetBestChain: new best=9657908608eeddce30390a30ac72b3348fd584c1b3cb917922707f9cfc01a488 height=1 difficulty=7 log2Work=13 log2ChainWork=13.044394 tx=2 date=2013-07-07 18:28:00 progress=0.000000
ProcessBlock: ACCEPTED
received block 7edd2add999ca4a7d3c6abbe827a9aa19ea3e0e782e80c299d22599a29ec1f34
SetBestChain: new best=7edd2add999ca4a7d3c6abbe827a9aa19ea3e0e782e80c299d22599a29ec1f34 height=2 difficulty=7 log2Work=13 log2ChainWork=14.022368 tx=3 date=2013-07-07 18:29:58 progress=0.000000
ProcessBlock: ACCEPTED
received block b22946daedabb93d4e9e28945278fd3d9f7ec601ce4aba1a25e6e203cf6fa41f
ERROR: AcceptBlock() : incorrect proof of work
ERROR: ProcessBlock() : AcceptBlock FAILED
Misbehaving: 192.241.209.212:9911 (0 -> 100) DISCONNECTING
Try using -debug and -printtarget and post the ERROR messages about block #3 being rejected again This gave me a little hint. FYI sunny, the code this was built from is here, it is slightly modified from your latest commit to include some additional suggested optimizations from Mike270. https://github.com/Zalfrin/primecoinThere may be a bug in the way the "phash" variable is replacing "pblock->GetHeaderHash();". Maybe phash needs to be updated within the loop starting on line 4640 of main.cpp Please be *very careful* with protocol related code. If you break the protocol all users on a fork caused by your build will be invalid. Please uncomment the print call in TargetGetNext() and try to reproduce the issue with block#3 rejection due to wrong target. The print is only turned on when use -debug and -printtarget |
|
|
|
|
It's okay for now. There was a shorter fork of about 50 blocks. I will look into the cause of that.
This type of situation is why the maturity is set at 3200 blocks. Currently the block rate on the network is very fast before difficulty catches up. So higher orphan rate is expected.
|
|
|
|
|
okay it appears most everyone is now on the longer fork now.
|
|
|
|
|
There appears to be a network fork at block#14214 just now. Please run this command
getblockhash 14215
and report your current block number
|
|
|
|
stuck at 2 blocks synced no matter how many connections i have received block 9657908608eeddce30390a30ac72b3348fd584c1b3cb917922707f9cfc01a488 SetBestChain: new best=9657908608eeddce30390a30ac72b3348fd584c1b3cb917922707f9cfc01a488 height=1 difficulty=7 log2Work=13 log2ChainWork=13.044394 tx=2 date=2013-07-07 18:28:00 progress=0.000000 ProcessBlock: ACCEPTED received block 7edd2add999ca4a7d3c6abbe827a9aa19ea3e0e782e80c299d22599a29ec1f34 SetBestChain: new best=7edd2add999ca4a7d3c6abbe827a9aa19ea3e0e782e80c299d22599a29ec1f34 height=2 difficulty=7 log2Work=13 log2ChainWork=14.022368 tx=3 date=2013-07-07 18:29:58 progress=0.000000 ProcessBlock: ACCEPTED received block b22946daedabb93d4e9e28945278fd3d9f7ec601ce4aba1a25e6e203cf6fa41f ERROR: AcceptBlock() : incorrect proof of work ERROR: ProcessBlock() : AcceptBlock FAILED Misbehaving: 192.241.209.212:9911 (0 -> 100) DISCONNECTING Try using -debug and -printtarget and post the ERROR messages about block #3 being rejected again |
|
|
|
This is the testnet checkpoint. There seems a bug somewhere allowing you to enter this state. Did you use the testnet at some point and what's the sequence of operations/events related to using testnet? Are you running a testnet node right now with main net node?
You know what, yeah I think I know how it happened, I'm messing around with the client to build a p2p pool, and I'm using the testnet flags and variables to let it know if its running as a pool node or a regular node. However it still shouldn't have entered this state even though you operated testnet mode. |
|
|
|
 getcheckpoint {
"synccheckpoint" : "221156cf301bc3585e72de34fe1efdb6fbd703bc27cfc468faa1cdd889d0efa0",
"height" : 0,
"timestamp" : 1373063882,
"subscribemode" : "advisory"
}
getblockhash 14131 93c94769cfde74003f65b7fac93c2908e166da50dfd118fc0fcfcd0a51b00348 This is the testnet checkpoint. There seems a bug somewhere allowing you to enter this state. Did you use the testnet at some point and what's the sequence of operations/events related to using testnet? Are you running a testnet node right now with main net node? |
|
|
|
{
"blocks" : 14131,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"errors" : "Warning: checkpoint on different blockchain fork, contact developers to resolve the issue",
"generate" : true,
"genproclimit" : 1,
"primespersec" : 156,
"pooledtx" : 0,
"testnet" : false
}Derp? Please run these command getcheckpoint getblockhash 14131 And post output Current checkpoint is still on genesis. So I don't expect this to pop up. |
|
|
|
|
I will incorporate Mike's suggestion of checking pindexBest.
Hang on.
|
|
|
|
Sorry for my earlier error on Market cap. The newest exchange rates and coin total (168,186.31) yields a cap of around 68k which would be 15th just behind CNC. The hourly mining rate is equivalent to 6 BTC (assuming 1 minute blocks and 20.41 coins per block as the last few have been) which wold be $500 at current exchange rates, still 3rd over.
Going according to plan isn't it  Looking forward to XPM's debut on the network mining income pie chart  |
|
|
|
Is there any clue to what kind of systems affected by this issue? I wonder whether my Intel Atom is just too slow to compete, BTW I have OpenSUSE 11.4.
From the reports I have gathered, it impacted some server systems with high thread count, yes it may impact atoms as it's threads are relatively slow. |
|
|
|
Ah, thank you, that makes more sense. Does that mean that the client intentionally throttles the stake mining thread? Otherwise I would expect to see at least one thread at 100% if you have any coins that are 30 days or older that haven't been staked yet.
Is there a command in ppcoind that can give me confirmation that it is trying to stake mine?
The stake minter thread is automatically running as long as the client wallet is running. If it couldn't run (e.g. locked wallet) it would give a message. Normally it shouldn't consume much cpu when it is minting. |
|
|
|
|
Good job Petrified! What primality test you are testing on your crawler?
|
|
|
|
Both fail on #9 in my Block Crawler: Block 2044Block 5355Of course that is dependent of my code for generating the chain being correct. You miss the first prime. The first prime is origin+1 for 2CC. |
|
|
|
Sorry, but aren't prime numbers supposed to be odd?
Yes that's why they are called origin, not prime. See my design paper or the bitcoin magazine article for the definition of prime chain origin. |
|
|
|
|
Bi-twin chain records only count even lengths. So we are waiting for the first TWN10 block (which is the bi-twin of 4 links)
|
|
|
|
|
Show Posts
