|
Crljeni
|
 |
June 15, 2014, 02:18:27 PM |
|
This shit coin needs to go back into development stage and re-launch at block 16k in a couple of weeks when all bugs are patched.
I'm out.
EDIT: Sandor shut your pool down, and your nodes. We need to kill the coin to get some attention from the dev.
What are we doing here? Trying daily to sync wallet !!!??? |
|
|
|
|
|
|
|
|
|
|
|
If you want to be a moderator, report many posts with accuracy. You will be noticed.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
|
|
|
primer-
Legendary
 Offline
Activity: 1092
Merit: 1000
|
|
June 15, 2014, 02:36:04 PM |
|
Heres another bug that cripples the database
ERROR: HashBurnData() : Burn transaction does not meet minimum number of confirmations 0 < 6
ERROR: CheckProofOfBurnHash() : hash doesn't match nBurnBits
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff > 000000023e1c0000000000000000000000000000000000000000000000000000
ERROR: bool CTxDB::LoadBlockIndex() : deserialize error on PoB index 16034
Error loading blkindex.dat
|
|
|
|
|
|
rfcdejong
|
|
June 15, 2014, 02:38:49 PM |
|
Anyone that has had syncing issues and has investigated it, please give me your *detailed* input please.
What I have noticed is that:
PoB blocks have DoS protection that bans good nodes if too many orphan PoB blocks are sent.
PoB blocks cannot be orphaned (yet), if an orphaned PoB block is sent, it will get rejected and not recorded anywhere.
I put such DoS protection to prevent any malicious activity, but it seems it is doing more harm that good.
I do not think the issue is in the PoS blocks. As for the stop at block 16000, I will have to create a hard fork from there, that is if I see more people wanting such fork.
The intermediate burn hash fix that takes affect at block 17000 fixes: A PoB block can be falsely rejected due to inaccuracy in floating point precision between two different machines. Some nodes will accept it and others will not (and this will not be able to get to the other blocks after it). This intermediate burn hash fix, does fix this, it is not a patch.
I wish i knew what the problem is, if it's PoS which causes issues then better remove PoS at all. Which open doors Do you know which code is added / changed for dcrypt and PoB ? If so and if doable i suggest to take a fork from vertcoin, ignore the Script-N PoW and implement code for dcrypt and PoB. Remove the PoS which causes only trouble combined with PoB. All i know is that vertcoin has the best code vs litecoin by directly adding code from bitcoin. And ofcourse offer a way to switch coins, best would be to let the new wallet work with the current blockchain, but that might be impossible because there is already PoS done. Maybe allow a service to exchange old coins to the new coins. Also burned coins should be able to be 'transfered' into the new coins. |
|
|
|
|
|
rfcdejong
|
|
June 15, 2014, 02:41:23 PM |
|
Heres another bug that cripples the database
ERROR: HashBurnData() : Burn transaction does not meet minimum number of confirmations 0 < 6
ERROR: CheckProofOfBurnHash() : hash doesn't match nBurnBits
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff > 000000023e1c0000000000000000000000000000000000000000000000000000
ERROR: bool CTxDB::LoadBlockIndex() : deserialize error on PoB index 16034
Error loading blkindex.dat
That happens when you have blocks in your blockchain newer than the latest valid block from another 'fork', a corrupted blockchain.. The dev could perhaps add a condition to be able to skip that a hash of "ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff" |
|
|
|
|
|
|
|
bitspender
|
|
June 15, 2014, 03:21:42 PM |
|
Just post the pool's config file, so we can all sync on those nodes!!
|
|
|
|
|
|
rfcdejong
|
|
June 15, 2014, 03:25:02 PM |
|
Just post the pool's config file, so we can all sync on those nodes!!
After a relaunch if you ask me, it would be nice when the wallet is also fixed so they don't get stuck on PoS or PoB blocks... |
|
|
|
|
|
rfcdejong
|
|
June 15, 2014, 03:56:17 PM |
|
pool is jumping back in blocks anyway, from 16148 back to 16080
slimcoin 2014-6-15 15:54:29 UTC 16080 0000001fcbf2d2f5ff2e304d4517f38b69ac384623f78534bde921b5e8392174 15.04 immature
slimcoin 2014-6-15 15:49:19 UTC 16148 0000001558f86806b2ea117cc1085bcd4573307ffbf91df13bafd8e6007be65e 14.63 immature
|
|
|
|
|
|
rfcdejong
|
|
June 15, 2014, 05:48:09 PM |
|
pool is jumping back in blocks anyway, from 16148 back to 16080
slimcoin 2014-6-15 15:54:29 UTC 16080 0000001fcbf2d2f5ff2e304d4517f38b69ac384623f78534bde921b5e8392174 15.04 immature
slimcoin 2014-6-15 15:49:19 UTC 16148 0000001558f86806b2ea117cc1085bcd4573307ffbf91df13bafd8e6007be65e 14.63 immature
and again from 16157 down to 16082 slimcoin 2014-6-15 17:34:44 UTC 16082 0000000485f1de64dd4d33d978c39ebf0f60fdb6b99c653aa3ef8981ba4bcbf9 14.97 immature slimcoin 2014-6-15 17:31:45 UTC 16157 0000002419e0d82cefc25ae9d7e05ef7301af2223ceb2e80e800eccd649f1c16 15.96 immature I would love to see the debug logs of that  The dev will need it too |
|
|
|
|
|
AizenSou
|
|
June 15, 2014, 06:13:51 PM |
|
Today is holiday so everyone's taking a break. sandor111 is no where to find. Happy instamining, dude. I'm out.
|
|
|
|
|
|
reflector
|
|
June 15, 2014, 06:46:51 PM |
|
are there any working nodes right now?
|
|
|
|
|
|
rfcdejong
|
|
June 15, 2014, 06:54:52 PM |
|
are there any working nodes right now?
i have no idea at the moment, will see tomorrow.. currently my wallets are down and i'm mining monero with gpu and cpu but the pool isn't really "instamine".. even thru it finds almost all blocks because it's the only one in the front of the chain.. the block target of 90 seconds is in place |
|
|
|
|
amanno44
Newbie
Offline
Activity: 24
Merit: 0
|
|
June 15, 2014, 07:33:07 PM |
|
are there any working nodes right now?
i have no idea at the moment, will see tomorrow.. currently my wallets are down and i'm mining monero with gpu and cpu but the pool isn't really "instamine".. even thru it finds almost all blocks because it's the only one in the front of the chain.. the block target of 90 seconds is in place What speeds would you say a 7950 could pull with monero...I'm getting about 25-30 h/s with my cpu |
|
|
|
|
|
rfcdejong
|
|
June 15, 2014, 08:23:53 PM |
|
are there any working nodes right now?
i have no idea at the moment, will see tomorrow.. currently my wallets are down and i'm mining monero with gpu and cpu but the pool isn't really "instamine".. even thru it finds almost all blocks because it's the only one in the front of the chain.. the block target of 90 seconds is in place What speeds would you say a 7950 could pull with monero...I'm getting about 25-30 h/s with my cpu i think it will do ~200 h/s, but that is just a suggestion. And it seems your cpu is slow My 4770 does ~200 h/s |
|
|
|
|
jadefalke
Legendary
Offline
Activity: 1457
Merit: 1014
|
|
June 15, 2014, 08:30:14 PM |
|
with 200h/s how many monero do you get per day?
|
|
|
|
|
|
rfcdejong
|
|
June 15, 2014, 08:35:23 PM |
|
Anyone that has had syncing issues and has investigated it, please give me your *detailed* input please.
What I have noticed is that:
PoB blocks have DoS protection that bans good nodes if too many orphan PoB blocks are sent.
PoB blocks cannot be orphaned (yet), if an orphaned PoB block is sent, it will get rejected and not recorded anywhere.
I put such DoS protection to prevent any malicious activity, but it seems it is doing more harm that good.
I do not think the issue is in the PoS blocks. As for the stop at block 16000, I will have to create a hard fork from there, that is if I see more people wanting such fork.
The intermediate burn hash fix that takes affect at block 17000 fixes: A PoB block can be falsely rejected due to inaccuracy in floating point precision between two different machines. Some nodes will accept it and others will not (and this will not be able to get to the other blocks after it). This intermediate burn hash fix, does fix this, it is not a patch.
We need an official statement about this! Are blocks past 17000 the fix for the wallet being stuck? Or simply a high possibility? What about the blockchain getting corrupted everytime the network falls back blocks? One small error results into a big domino effect crumbling the current relative small distributed peer-to-peer network. Starting up as a decentralized network having some masternodes is a good solution to fix the sync problems when the wallet is fixed. imo - Steps to take: After the official statement work to be done something like this 1) Fix the wallet - is the 17000+ block enough? 2) Setup 6 master nodes on test network 3) Setup 3 seed nodes on test network 4) Alter OP topic with addnodes to the master nodes 5) Switch nodes to normal network and make it a fair relaunch at block 16000 - instruct pool owners PS: Let others setup some master nodes until the network speed is secure, write a guide |
|
|
|
|
|
rfcdejong
|
|
June 15, 2014, 08:36:12 PM
Last edit: June 15, 2014, 08:55:05 PM by rfcdejong |
|
with 200h/s how many monero do you get per day?
With a mining difficulty of 300000000 nearly 1 XMR a day, yes the diff is high! but the diff is even higher... 2014-Jun-15 22:54:12.010615 BH: 86883, DIFF: 410702438, HR: 6845040 H/s look at http://pool.cryptoescrow.eu/ and see you get only 0.67 XMR with 200 h/s |
|
|
|
|
|
slimcoin (OP)
|
|
June 15, 2014, 09:02:03 PM |
|
Are blocks past 17000 the fix for the wallet being stuck? Or simply a high possibility? What about the blockchain getting corrupted everytime the network falls back blocks? One small error results into a big domino effect crumbling the current relative small distributed peer-to-peer network. Starting up as a decentralized network having some masternodes is a good solution to fix the sync problems when the wallet is fixed. The origin for the blockchain forks is the PoB block discrepancies in hashes. All blocks after 17000 will be fixed of that. The blockchain corruption you talk about is not really corruption and is an easy fix, I am working on now. It does look like a good idea to have a fair relaunch at block 16000 with a few master-nodes as currently, no one but a select few people on the correct blockchain are able to mine. Also, a relaunch would get everyone on the same place. Anyone that has comments about this, I would like to hear your ideas. Also, adding a DNS seed node would definitely add stability to the network. |
-Much Donate
BTC-1D5pnma7E1CP6cquHujycVy79EyXJ3eY
|
|
|
tilteer
Newbie
Offline
Activity: 29
Merit: 0
|
|
June 15, 2014, 09:06:10 PM |
|
Do we lose the coins we already have if there is a relaunch?
|
|
|
|
|
|
reflector
|
|
June 15, 2014, 09:10:52 PM |
|
Are blocks past 17000 the fix for the wallet being stuck? Or simply a high possibility? What about the blockchain getting corrupted everytime the network falls back blocks? One small error results into a big domino effect crumbling the current relative small distributed peer-to-peer network. Starting up as a decentralized network having some masternodes is a good solution to fix the sync problems when the wallet is fixed. The origin for the blockchain forks is the PoB block discrepancies in hashes. All blocks after 17000 will be fixed of that. The blockchain corruption you talk about is not really corruption and is an easy fix, I am working on now. It does look like a good idea to have a fair relaunch at block 16000 with a few master-nodes as currently, no one but a select few people on the correct blockchain are able to mine. Also, a relaunch would get everyone on the same place. Anyone that has comments about this, I would like to hear your ideas. Also, adding a DNS seed node would definitely add stability to the network. Relaunch at 16000 sounds good. I can host a DNS seed node if need be. |
|
|
|
|
|
