 Show Posts
|
|
Pages: [1] 2 »
|
it was Zero Connection now at-least 1 connection is there after addnode to 37.233.101.167
if you have more node send me Thanks
You can try adding 104.236.106.51 as well, and if you like IPv6 2604:a880:800:10::484:4001 |
|
|
|
On wallet synching issues: Yeah, I'm still having issues. I think I got some corrupt data in my copy of the blockchain. All the "easy" fixes failed, so I'm currently resynching from zero. Tek synchs almost as slow as bitcoin, so it'll be a day or two before I know, but so far it's synching smoothly. Since all of you who posted blocks you were stuck at or timelines (20 hrs, etc) were different, I think the issue is probably local for all of us. I was nearly 2 weeks behind. I'm considering putting up another version of my wallet on a droplet or something like, so I can compare performance. It is quite likely that my local problems come about from having too much going on in my machine  Do you know about zram? To get a good performance test in a 1GB RAM droplet, be sure to setup zram or you may run your system out of RAM. Or so I've heard.  |
|
|
|
he he
withdraw:
TekCoin BghpfgumTT8zrSEMLf4LwHi6PQAvBNLuJj 178.32437732 TEK Yes 2014-12-03 00:01:04
Processed TrxID: 1f68c822163d13bcd30b20a5074e3a4e105d980ddcf22c69cf3b0de81ce70443 @ 2014-12-03 02:42:06
+TekCoin BghpfgumTT8zrSEMLf4LwHi6PQAvBNLuJj 450.00000000 TEK Yes 2014-12-02 23:58:58
Processed TrxID: 4e38584354df25cfb594ff4a19dcedd58e684841f332291e883952912b7f1eaa @ 2014-12-03 02:12:04
TekCoin BghpfgumTT8zrSEMLf4LwHi6PQAvBNLuJj 450.00000000 TEK Yes 2014-12-02 23:57:33
Processed TrxID: 18f591bd2678c17e7387b9d2f20622fe9a05b766db0a72bdad819af21ac04058 @ 2014-12-03 00:06:04
+TekCoin BghpfgumTT8zrSEMLf4LwHi6PQAvBNLuJj 450.00000000 TEK Yes 2014-12-02 23:56:24
Processed TrxID: fdaadf5393257ac2bd57bb582f7d724c6b7b3cd3819120a903c0ceec1272722e @ 2014-12-03 01:40:06
+TekCoin BghpfgumTT8zrSEMLf4LwHi6PQAvBNLuJj 450.00000000 TEK Yes 2014-12-02 23:54:54
Processed TrxID: 3ea5538dbe558b13efbffc117c9f5eb068a95f53f3757a9c9d536d5b7a89fb8c @ 2014-12-03 01:08:05
TekCoin BghpfgumTT8zrSEMLf4LwHi6PQAvBNLuJj 450.00000000 TEK Yes 2014-12-02 23:53:53
Processed TrxID: 983d47a04aca6c8cecca33ff9e695b5a2918f7284e7be12e9a96e13e03c4c501 @ 2014-12-03 00:36:07
TekCoin BghpfgumTT8zrSEMLf4LwHi6PQAvBNLuJj 450.00000000 TEK Yes 2014-12-02 23:52:45
Processed TrxID: af001384590341bd78d90305baa79eedaa8f1a8fb7a89d8bf1c16a04b139617a @ 2014-12-03 00:04:06
-----------------------------------------------------
actually received
Status: 1245 confirmations
Date: 03.12.14 09:12
From: unknown
To: BghpfgumTT8zrSEMLf4LwHi6PQAvBNLuJj (own address, label: main)
Credit: 449.9998 TEK
Net amount: +449.9998 TEK
Transaction ID: 4e38584354df25cfb594ff4a19dcedd58e684841f332291e883952912b7f1eaa
Status: 1282 confirmations
Date: 03.12.14 08:40
From: unknown
To: BghpfgumTT8zrSEMLf4LwHi6PQAvBNLuJj (own address, label: main)
Credit: 449.9998 TEK
Net amount: +449.9998 TEK
Transaction ID: fdaadf5393257ac2bd57bb582f7d724c6b7b3cd3819120a903c0ceec1272722e
Status: 1316 confirmations
Date: 03.12.14 08:09
From: unknown
To: BghpfgumTT8zrSEMLf4LwHi6PQAvBNLuJj (own address, label: main)
Credit: 449.9998 TEK
Net amount: +449.9998 TEK
Transaction ID: 3ea5538dbe558b13efbffc117c9f5eb068a95f53f3757a9c9d536d5b7a89fb8c
not present transaction ID:
1f68c822163d13bcd30b20a5074e3a4e105d980ddcf22c69cf3b0de81ce70443
18f591bd2678c17e7387b9d2f20622fe9a05b766db0a72bdad819af21ac04058
983d47a04aca6c8cecca33ff9e695b5a2918f7284e7be12e9a96e13e03c4c501
af001384590341bd78d90305baa79eedaa8f1a8fb7a89d8bf1c16a04b139617a
All of those cryptsy withdrawls are in the blockchain, Arsenay. You can check the blockchain explorer. I suggest building and running the newest version. If upgrading your gui build environment is not possible, try running a headless tekcoind instead. |
|
|
|
Everything in the blockchain indicates that the address received the money. "Not yet redeemed," just means that it has not been spent yet. Are you sure you're synced up? There are currently 681469 blocks. Yeah, everything seems like it should be in my wallet, the wallet says I am at block 681834 right now. Why the hell cant I see the transaction in my wallet... edit: something weird is going on.. i ran both a salvage and repair wallet and I now have a different address.. Will try again. very wtf? Is "681834" blocks a typo? That is 300 blocks ahead of my wallet and I'm certain I'm on the correct chain. |
|
|
|
Everything in the blockchain indicates that the address received the money. "Not yet redeemed," just means that it has not been spent yet. Are you sure you're synced up? There are currently 681469 blocks. |
|
|
|
Hey Michael I might have to dump my 60K and check out PPC, That might be something you wana watch OWWWW Good job! I dumped my 50k several weeks back at a 33%+ BTC loss, and an even nicer fiat loss. Hee-hee, shamone! You dump. I buy. I stake  I'm with you, bro. |
|
|
|
Noise23, can you explain the purpose of the new SplitThreshold code and how it affects staking, please? I think I understand it after reviewing the code, but I'd rather hear it from you. |
|
|
|
Hello All, I'm new to JPC and I'm having trouble synchronizing my wallet past block 500000. I found the following information in my debug.log: 08/16/14 14:30:01 ERROR: CheckProofOfStake() : INFO: read txPrev failed
08/16/14 14:30:01 WARNING: ProcessBlock(): check proof-of-stake failed for block ac923d44cbeea785da2464fc5235f3aec6d046af9164e2dc33f700d91d7cc719
08/16/14 14:30:04 ERROR: AcceptBlock() : rejected by hardened checkpoint lock-in at 500001
08/16/14 14:30:04 ERROR: ProcessBlock() : AcceptBlock FAILED
08/16/14 14:30:04 Misbehaving: 67.8.38.82:15371 (0 -> 100) DISCONNECTING
08/16/14 14:30:04 disconnecting node 67.8.38.82:15371
I built my wallet from from the latest source on github (ece0c8abf7). Any help would be greatly appreciated. fwiw, I've git reset my local repo to the PoS Bugfix commit (df207d524c), rebuilt, and I'm trying to sync the blockchain from scratch now. I wonder if I'll run into the same issue. I was able to sync the whole chain from scratch from the PoS Bugfix commit (v1.4.1.0), but not from the latest commit (v1.5.0 Final Beta). Bug confirmed and fixed. I'm syncing past 500000 now. If you're here dev, thank you. https://github.com/rtc29462/JackpotCoin/issues/2 |
|
|
|
Hello All, I'm new to JPC and I'm having trouble synchronizing my wallet past block 500000. I found the following information in my debug.log: 08/16/14 14:30:01 ERROR: CheckProofOfStake() : INFO: read txPrev failed
08/16/14 14:30:01 WARNING: ProcessBlock(): check proof-of-stake failed for block ac923d44cbeea785da2464fc5235f3aec6d046af9164e2dc33f700d91d7cc719
08/16/14 14:30:04 ERROR: AcceptBlock() : rejected by hardened checkpoint lock-in at 500001
08/16/14 14:30:04 ERROR: ProcessBlock() : AcceptBlock FAILED
08/16/14 14:30:04 Misbehaving: 67.8.38.82:15371 (0 -> 100) DISCONNECTING
08/16/14 14:30:04 disconnecting node 67.8.38.82:15371
I built my wallet from from the latest source on github (ece0c8abf7). Any help would be greatly appreciated. fwiw, I've git reset my local repo to the PoS Bugfix commit (df207d524c), rebuilt, and I'm trying to sync the blockchain from scratch now. I wonder if I'll run into the same issue. I was able to sync the whole chain from scratch from the PoS Bugfix commit (v1.4.1.0), but not from the latest commit (v1.5.0 Final Beta). |
|
|
|
Hello All, I'm new to JPC and I'm having trouble synchronizing my wallet past block 500000. I found the following information in my debug.log: 08/16/14 14:30:01 ERROR: CheckProofOfStake() : INFO: read txPrev failed
08/16/14 14:30:01 WARNING: ProcessBlock(): check proof-of-stake failed for block ac923d44cbeea785da2464fc5235f3aec6d046af9164e2dc33f700d91d7cc719
08/16/14 14:30:04 ERROR: AcceptBlock() : rejected by hardened checkpoint lock-in at 500001
08/16/14 14:30:04 ERROR: ProcessBlock() : AcceptBlock FAILED
08/16/14 14:30:04 Misbehaving: 67.8.38.82:15371 (0 -> 100) DISCONNECTING
08/16/14 14:30:04 disconnecting node 67.8.38.82:15371
I built my wallet from from the latest source on github (ece0c8abf7). Any help would be greatly appreciated. fwiw, I've git reset my local repo to the PoS Bugfix commit (df207d524c), rebuilt, and I'm trying to sync the blockchain from scratch now. I wonder if I'll run into the same issue. |
|
|
|
I built my wallet from from the latest source on github (ece0c8abf7). Any help would be greatly appreciated.
What gcc do you use? I have 4.9.1. > gcc --version gcc (SUSE Linux) 4.8.1 20130909 [gcc-4_8-branch revision 202388] |
|
|
|
Hello All, I'm new to JPC and I'm having trouble synchronizing my wallet past block 500000. I found the following information in my debug.log: 08/16/14 14:30:01 ERROR: CheckProofOfStake() : INFO: read txPrev failed
08/16/14 14:30:01 WARNING: ProcessBlock(): check proof-of-stake failed for block ac923d44cbeea785da2464fc5235f3aec6d046af9164e2dc33f700d91d7cc719
08/16/14 14:30:04 ERROR: AcceptBlock() : rejected by hardened checkpoint lock-in at 500001
08/16/14 14:30:04 ERROR: ProcessBlock() : AcceptBlock FAILED
08/16/14 14:30:04 Misbehaving: 67.8.38.82:15371 (0 -> 100) DISCONNECTING
08/16/14 14:30:04 disconnecting node 67.8.38.82:15371
I built my wallet from from the latest source on github (ece0c8abf7). Any help would be greatly appreciated. |
|
|
|
|
Danbi, maybe you could share your list of trusted nodes here? Then we could add them all into our configs with a connect line and stay on the right chain and not need to rely just on your IP.
Or if somebody has a listening node (don't do this) that is able to stay on the correct chain, maybe they could share their getpeerinfo, so that we can add some data for connect lines.
|
|
|
|
i love to talk in pictures  : u can see diamond network as a herd of sheep's with a few shepherd dogs and a shepherd shepherd is the foundation shepherd dogs is the network stabilization tool like permanent nodes seed nodes checkpoint wallet filter and so on from time to times wolves try their luck and create confusion but soon repelled by shepherd dogs but some sheep's special if they don't stay close with the shepherd and the shepherd dogs can become victim to the wolves long story short: stay with our suggested conf setting and wallet upgradessome people might suggest: leave the sheep's on their own they will follow their instincts (base wallet code) and live and prosper try that with real sheep's and tell me how many left after a year or two Your description sounds more like a centralized fiat system than a decentralized cryptocurrency. In the United States, your shepherd relates to The Fed, and your shephard's dogs are the Secret Service. And that's not working that well, thus we are all interested in cryptocurrencies. A new version of diamond needs to be released asap that fixes this genesisblock bug that Danbi and Polanskiman are citing. When a bug causes a blockchain fork, the bug that causes it must be addressed and fixed otherwise it might be hard to get Cryptsy and other exchanges to trust that it won't happen again. The bitcoin block fork of a year ago. It was caused by a bug and fixed with a patch: http://www.reddit.com/r/Bitcoin/comments/1a51xx/now_that_its_over_the_blockchain_fork_explained/Having everyone connect to one host to get the correct block chain is a temporary measure and it will only work if the all miners on that chain hash faster than the other. This may or may not happen, and the latest news according to pallas and Atomicca regarding the falling difficulty level might indicate that danbi's chain is failing. We need a fix for the bug asap. The longer this goes on the more money is lost. Yes it is a description of a centralised network, but at the moment this is the only way to ensure Diamonds integrity. Ideally there would be no time wasters who try to bring us down so we didn't have to resort to this configuration. But this is not an ideal world. Leave Cryptsy to us, if they really fork we will inform them. It's not the first and the last time we will deal with them and anyone following this thread knows the drill. Danbis chain is not failing, it's protected well enough to withstand whatever these time wasters throw at us. Yes we need a fix. But the same bug is present in every percoin/novacoin besed coin. A lot of people reported it but no one came with the solution so it will involve a lot of analytical work to pinpoint the cause, but this takes time. The link you provided adds nothing to the solution of the problem and it is something different that we're dealing with. Jhed - stop being melodramatic as it's not helping anyone, apart from time wasters. According to this page at peercoin, pszTimestamp is supposed to have a max of 91 chars: https://github.com/Peershares/Peershares/wiki/Genesis-Block-(Starting-a-New-Blockchain-Instance) But ours is 117 characters: https://github.com/DMDcoin/Diamond/blob/master/src/main.cpp#L2649Is that the problem? |
|
|
|
Hello, anyone that can help
After downloading the blockchain+data file and replacing relevant files and restarting the wallet it seems to be in sinc and working fine. However I tried sending a few coins to cryptsy as a test and they are not getting there, the wallet says over 50 confirmations but no coins at cryptsy.
Does anyone know what is happening, why the coins aren't making it to cryptsy?
check if transaction id is visible here http://diamond.danbo.bg:2750/chain/Diamondif not u are on wrong chain please update us if coins arrived a cryptsy so its ckear they on right chain too I checked the transaction id and found a match. It was there with the amount of coins I sent. The coins still haven't turned up at cryptsy with over 150 confirmations on my wallet. Nobody should be trying to send money into Cryptsy right now. There was previous claims by cryptonit that cryptsy was on danbi's chain, but as you've noticed, they are not. In your case, your money will show up when Cryptsy gets on danbi's chain. Maybe it already has? But in any case Cryptsy is not going to be happy when they learn the bug is not fixed yet. |
|
|
|
i love to talk in pictures : u can see diamond network as a herd of sheep's with a few shepherd dogs and a shepherd shepherd is the foundation shepherd dogs is the network stabilization tool like permanent nodes seed nodes checkpoint wallet filter and so on from time to times wolves try their luck and create confusion but soon repelled by shepherd dogs but some sheep's special if they don't stay close with the shepherd and the shepherd dogs can become victim to the wolves long story short: stay with our suggested conf setting and wallet upgradessome people might suggest: leave the sheep's on their own they will follow their instincts (base wallet code) and live and prosper try that with real sheep's and tell me how many left after a year or two Your description sounds more like a centralized fiat system than a decentralized cryptocurrency. In the United States, your shepherd relates to The Fed, and your shephard's dogs are the Secret Service. And that's not working that well, thus we are all interested in cryptocurrencies. A new version of diamond needs to be released asap that fixes this genesisblock bug that Danbi and Polanskiman are citing. When a bug causes a blockchain fork, the bug that causes it must be addressed and fixed otherwise it might be hard to get Cryptsy and other exchanges to trust that it won't happen again. The bitcoin block fork of a year ago. It was caused by a bug and fixed with a patch: http://www.reddit.com/r/Bitcoin/comments/1a51xx/now_that_its_over_the_blockchain_fork_explained/Having everyone connect to one host to get the correct block chain is a temporary measure and it will only work if the all miners on that chain hash faster than the other. This may or may not happen, and the latest news according to pallas and Atomicca regarding the falling difficulty level might indicate that danbi's chain is failing. We need a fix for the bug asap. The longer this goes on the more money is lost. |
|
|
|
jhed
Newbie
*
Online Online
Activity: 3
Posts: 3 nice try appear out of nowhere after a attack with 3 post account all at DMD and try motivate people dont to use the stable point of our network i would say thats part2 of an attack plan multiple attacks failed now try the social one..... people trust in danbi's suggested solution we are on same chain as cryptsy dmd multipool is one same chain I'm not asking anybody to trust me. I'm just telling you all that you should see something in your ~/.Diamond/debug.log about 193.68.21.19 misbehaving. If that made it in my debug.log it should be in others. Here it is again look, look for it in your debug.log: ProcessBlock: ORPHAN BLOCK, prev=000000000302b0af011c received block 000000000302b0af011c ProcessBlock: ORPHAN BLOCK, prev=0000000004e6b27a0790 received block 0000000000d652bceaa2 connection timeout ProcessBlock: ACCEPTED received block 00000000078b6cf20c99 Misbehaving: 193.68.21.19:17771 (0 -> 100) DISCONNECTING disconnecting node 193.68.21.19:17771 ERROR: ProcessBlock() : block with too little proof-of-work Does nobody else see this in their logs? I'd say it's just a bug in my version diamondd but given that the whole damn block chain forked around the time this was logged, it wasn't just me. Let me share a little story with you: Besides the 193.68.21.19 node I pledged to run for the community (many months ago), I do run few more nodes, which I don't announce but use for tests and .. sometimes as traps for such situations. As I was not paying attention (todo entry already -- provide real-time monitoring) they all were on the wrong chain. All of them were receiving that exact message in their logs. At the 193.68.21.19 they were disconnected/banned too, for the very same reason. I don't want to get too technical on this, but it is apparently this is a form of attack on the network. The mere reason those nodes ended up that way was they were not properly configured (most are experimental, remember). Danbi, Did you not just illustrate the problem here? Everyone's diamond.conf was configured with a single addnode. All the attacker had to do was compromise the block chain at 193.68.21.19 and the whole diamond network was forked. Unless it is in fact a bug as polanskiman is suggesting. In any case, wouldn't it be a good idea to do away with the single point of failure and let the network be decentralized as it was designed to be? Remove all "addnodes" and "connect" as well as remove the "listen=0" and "noirc=0" statements and let the software do it's thing to find out on it's own which chain to use? |
|
|
|
Just now I changed it to : listen=0 noirc=1 connect=193.68.21.19 And I still get: diamondd: kernel.cpp:410: unsigned int GetStakeModifierChecksum(const CBlockIndex*): Assertion `pindex->pprev || pindex->GetBlockHash() == (!fTestNet ? hashGenesisBlock : hashGenesisBlockTestNet)' failed. Aborted Though may I ask why you want me to set all that? It effectively makes me a non-participator in the diamond network giving all network control to 193.68.21.19. You are getting the assertion error where the index.dat file gets corrupted due to a flood of orphans. Other nodes you are connected to are feeding you crap. Obviously you also need to replace the blockchain with the one provided in the OP. Then start the wallet. The index file is corrupted so making those changes to the .conf is useless if you don't replace the blockchain files first. Basically delete all files except your wallet.dat and the diamond.conf files and replace with the one in the OP. Using connect=IP and listen=0 makes you indeed a "leecher" if I may say so but this is temporary. You can then revert and change to addnode=ip and listen=1 later on. This is TEMPORARY. The index corruption issue is not something specific to Diamond. A lot more coins have the same problem and to this date there has been no fixes. It's happened to a lot more coins? Can you link to a couple so that I can confirm that this won't happen again in the future? I have a copy of the block chain that generates this error if somebody wants to look at it. |
|
|
|
jhed
Newbie
*
Online Online
Activity: 3
Posts: 3 nice try appear out of nowhere after a attack with 3 post account all at DMD and try motivate people dont to use the stable point of our network i would say thats part2 of an attack plan multiple attacks failed now try the social one..... people trust in danbi's suggested solution we are on same chain as cryptsy dmd multipool is one same chain I'm not asking anybody to trust me. I'm just telling you all that you should see something in your ~/.Diamond/debug.log about 193.68.21.19 misbehaving. If that made it in my debug.log it should be in others. Here it is again look, look for it in your debug.log: ProcessBlock: ORPHAN BLOCK, prev=000000000302b0af011c received block 000000000302b0af011c ProcessBlock: ORPHAN BLOCK, prev=0000000004e6b27a0790 received block 0000000000d652bceaa2 connection timeout ProcessBlock: ACCEPTED received block 00000000078b6cf20c99 Misbehaving: 193.68.21.19:17771 (0 -> 100) DISCONNECTING disconnecting node 193.68.21.19:17771 ERROR: ProcessBlock() : block with too little proof-of-work Does nobody else see this in their logs? I'd say it's just a bug in my version diamondd but given that the whole damn block chain forked around the time this was logged, it wasn't just me. Not getting this at all. Please read: https://bitcointalk.org/index.php?topic=580725.msg8115151#msg8115151What is your diamond.conf config? Please post it here. Just now I changed it to : listen=0 noirc=1 connect=193.68.21.19 And I still get: diamondd: kernel.cpp:410: unsigned int GetStakeModifierChecksum(const CBlockIndex*): Assertion `pindex->pprev || pindex->GetBlockHash() == (!fTestNet ? hashGenesisBlock : hashGenesisBlockTestNet)' failed. Aborted Though may I ask why you want me to set all that? It effectively makes me a non-participator in the diamond network giving all network control to 193.68.21.19. |
|
|
|
I'm getting this error upon closing and restarting diamondd now. Maybe this has something to do with the chain fork. Is this the place to go for tech support? diamondd: kernel.cpp:410: unsigned int GetStakeModifierChecksum(const CBlockIndex*): Assertion `pindex->pprev || pindex->GetBlockHash() == (!fTestNet ? hashGenesisBlock : hashGenesisBlockTestNet)' failed.
What's you wallet version? Diamond v2.0.3 https://github.com/DMDcoin/Diamond/archive/Diamond-2.0.3.tar.gz |
|
|
|
|
