|
why is everyone posting "res" ?!
|
|
|
|
I managed to get past my previous problem, and got my P2Pool running after many little issues, but I have another problem now lol.
P2Pool connects to magid and hands out shares correctly to my workers, but when I finally get a block it says it is generated in the P2Pool frontend, but doesn't appear in chainz.crptoid. magid is sending an error when the block is sent ..
------------------------------------------------------------------
received: block (1086 bytes)
received block 0000000020f34f02992e
CBlock(hash=0000000020f34f02992ec94030dc97d1c7279496ad20eaebfe5257e1e5ab3450, ver=2, hashPrevBlock=3917774245be0396f3d674219508b61e015031fd5fbb8dd769f63f64aabddfd7, hashMerkleRoot=09ae9fa96f86e37e3872da61b25aae70d3179a97dcfd99a739da92ca2a5f2698, nTime=1527403186, nBits=1d008eb7, nNonce=2818764751, vtx=1, vchBlockSig=)
CTransaction(hash=9d0e3ae70c, nTime=1, ver=1, vin.size=0, vout.size=0, nLockTime=0)
vMerkleTree:
ERROR: CheckBlock() : first tx is not coinbase
ERROR: ProcessBlock() : CheckBlock FAILED
Warning: Local node 127.0.0.1:54350 misbehaving (delta: 100)!
nHeight: 1836086
nHeight: 1836086
nWeightTot: 8588
-----------------------------------------------------------------------
I checked on cryptoid and the block version is 6. On P2Pool transaction the block version is 4. I don't know if this is the issue, or something more complex. I'm running Ubuntu 16.4 and have tried P2Pool-master and P2Pool-feldenthorne and they both do the same thing. Oh and I have installed magi-hash also.
Any ideas anyone ??
You're confusing POS/POW for the built blocks... |
|
|
|
Hm I see
for the last 24 hours ive been getting transaction each 1hour/1hour half, then suddenly 5 hours with nothing. with 2.3TH, seems strange. its only 000 uncomfirmed, but I can see the round rewards.
you get an transaction every time a block is found |
|
|
|
Hi, been mining for 1.5 day, just checked I have not recived any dcr for 5 hours. The miner is running, and the pool is reg my hash. And everything seems fine in the webwindow.
Whats wrong?
diff is high, just wait a bit until a block has been found |
|
|
|
Does any one know why blocks from more than 19 hours before are being added into the blockchain? Wasn't the block drift set to 2 hours? How's this possible?
because they "walk back in time" - every of the hacker crafted block has a timestamp previous to the one before.. at some point you are at 19h ... if he would mine some more blocks, you'd be at 24h.. then at 36.. etc. at a certain point in the future. since the coin compares current time with the latest block's timestamp it thinks "wow, the old block is hella old, I gotta lower difficulty so someone finally gets the chain moving!" and thus lowers the diff.. the more blocks come, the lower the diff.. at a certain point it's at the minimum but still the manipulated blocks fly in so it will never retarget up again until a "recent" block is mined with correct timestamp. PS: I've explained all that stuff previously already  Ah okay ty, I was just confused because the drift time is meant to prevent this. Am I wrong in that regard? No you're (almost) correct but if you produce a lots of blocks, you can always use the max drift time for each subsequent block. So for example Block 1 -> Block 2 uses max drift, then you can use again max drift between block 2 > 3 which leads to an even bigger drift from 1->3 ... and so on |
|
|
|
Does any one know why blocks from more than 19 hours before are being added into the blockchain? Wasn't the block drift set to 2 hours? How's this possible?
because they "walk back in time" - every of the hacker crafted block has a timestamp previous to the one before.. at some point you are at 19h ... if he would mine some more blocks, you'd be at 24h.. then at 36.. etc. at a certain point in the future. since the coin compares current time with the latest block's timestamp it thinks "wow, the old block is hella old, I gotta lower difficulty so someone finally gets the chain moving!" and thus lowers the diff.. the more blocks come, the lower the diff.. at a certain point it's at the minimum but still the manipulated blocks fly in so it will never retarget up again until a "recent" block is mined with correct timestamp. PS: I've explained all that stuff previously already |
|
|
|
Block 2155850 to 2206272 were mined with super-low-diff for the hackers.. About 35 Millions in a few hours raher than a few weeks.. all alone for one person or group..
What's to say that others didn't also benefit from this? Wasn't the chain open for anyone to mine on those algos? If the difficulty went down with an exploit, it went down for everyone. Right? only if you had a modified wallet which rejected all transactions. they're not THAT dumb and addittionally spammed the network with lots of micro-transactions which brought normal wallets to become unresponsive. obviously their wallets/daemons are modified and simply don't mine those transactions (you can see that also from the block explorer, all their blocks only contain 1 TX, the TX to themselves). So, the attack also targeted pools and miners to only allow the hackers to benefit from the low difficulty? Those hackers planned ahead. Well.. check the first post of the thread.. it isn't the first time |
|
|
|
Block 2155850 to 2206272 were mined with super-low-diff for the hackers.. About 35 Millions in a few hours raher than a few weeks.. all alone for one person or group..
What's to say that others didn't also benefit from this? Wasn't the chain open for anyone to mine on those algos? If the difficulty went down with an exploit, it went down for everyone. Right? only if you had a modified wallet which rejected all transactions. they're not THAT dumb and addittionally spammed the network with lots of micro-transactions which brought normal wallets to become unresponsive. obviously their wallets/daemons are modified and simply don't mine those transactions (you can see that also from the block explorer, all their blocks only contain 1 TX, the TX to themselves). |
|
|
|
|
Block 2155850 to 2206272 were mined with super-low-diff for the hackers.. About 35 Millions in a few hours raher than a few weeks.. all alone for one person or group..
|
|
|
|
Since nothing really was done about the previous attacks (only a band-aid), the attackers now simply use two algos to fork the chain for their own use and are gaining millions:  Both algos, scrypt and lyra2re can be rented easily for a few bucks at nicehash, they simply send one block scrypt, after that a block lyra2re and so on and all with manipulated timestamps thus lowering diff to lowest possible mining several blocks per minute like this |
|
|
|
Thanks for your quick response, a bit new.
stratum+tcp://dcr.suprnova.cc:3256 what about this one for D9 since its asic. or just stick with the nicehash port as you recommended ?
If the asic port works fine for you, just stick with it |
|
|
|
Hi, I am getting my D9 tomorrow, and I am looking for a good pool for it, how is suprnova ? and what stratum port should I Use? I am really happy with my x10 on suprnova.
Cheers
Use the nicehash Port and you should be fine |
|
|
|
Hi,
I have a Inno D9, may I know should I connect to NiceHash port 2255 or Asic Stratum port 3256? Which one is more efficient?
thanks,
ctan6611
The asic Port but you can just try both for a few hours and then stick to the one which works best for you |
|
|
|
Is anyone having problems with Supernova pool today, mining zencash? I am having no shares.... since yesterday afternoon.
It has been working ok for me. Suprnova is usually pretty good with flagging on their website if they have an issue with on the pool side. I remember with one of their pools they provided no fee and 15 per cent additional coins because the pool was down intermittently throughout the day. So if there is a problem it should say on homepage. No problems on suprnova. Make sure you restart your miner, you should then see hashes after a few seconds on the dashboard |
|
|
|
|
Doggy and cat translation reserved
|
|
|
|
Can't connect to the network at version 1.0.0.3 and version 1.0.0.4 why?
You have to delete everything but wallet.dat and re-sync with 1.0.0.3 because the upgrade/hardfork failed at 1.0.0.4 I've downgraded suprnova as well and it's hashing fine again on the old wallet... |
|
|
|
|
Would be nice if you guys would have posted an update regarding your failed hardfork.. The only instructions I could find was on discord that a downgrade to 1.0.0.3 is requested and a resync is needed..
|
|
|
|
|
Show Posts
