Topic: [ANN] Catcoin - 0.9.3.0 - page 11. (Read 57711 times)
Prohashing has updated to 9.3.0
Of charts and algos.
Here's the CAT network over the past 24 hours:
Some comments. Yesterday we got a long string of blocks from our favorite empty block assembler and had a nice bounce. Our algo worked exactly as it should - diff rose to get us back to our average, and then came back down. The rest of the chart is most important, however, as it shows the network with more 24/7 hash rate. That's representative of what we've seen the past two years and it's a good thing!
As many CATs know, our challenge from launch was adjusting the algo to better sail the waves in the ASIC world that didn't exist when CAT was born. While our current algo isn't 'perfect' - and as much as we've been looking and testing to find one, we're not sure a perfect algo exists - it has been doing a very good job. We have the rapid response when pools switch in, we have decent recovery when they leave, and blocks have been getting closer to our 10 minute average than they have since 2013. There's a cost to that, though. In order to be this responsive yet lock-in the block rate, we need a minimum amount of 24/7 miners. When miners take a break from the network, it leaves longer blocks and more room for intruders to play. When we have enough hash, there's less opportunity for disruption and things flow really well.
I'm probably preaching to the choir here, but we've entered another age of ASICs with the continued delivery of Antminer L3+ and A4 Dominators. It's more difficult to find A2s and their 110 MH/s on MRR these days, and the average rental is in the 500 MH/s range and there are some 1 and 1.5 GH rigs available. We have to keep this new environment in mind as we work toward 9.4.0.
Here's the CAT network over the past 24 hours:
Some comments. Yesterday we got a long string of blocks from our favorite empty block assembler and had a nice bounce. Our algo worked exactly as it should - diff rose to get us back to our average, and then came back down. The rest of the chart is most important, however, as it shows the network with more 24/7 hash rate. That's representative of what we've seen the past two years and it's a good thing!
As many CATs know, our challenge from launch was adjusting the algo to better sail the waves in the ASIC world that didn't exist when CAT was born. While our current algo isn't 'perfect' - and as much as we've been looking and testing to find one, we're not sure a perfect algo exists - it has been doing a very good job. We have the rapid response when pools switch in, we have decent recovery when they leave, and blocks have been getting closer to our 10 minute average than they have since 2013. There's a cost to that, though. In order to be this responsive yet lock-in the block rate, we need a minimum amount of 24/7 miners. When miners take a break from the network, it leaves longer blocks and more room for intruders to play. When we have enough hash, there's less opportunity for disruption and things flow really well.
I'm probably preaching to the choir here, but we've entered another age of ASICs with the continued delivery of Antminer L3+ and A4 Dominators. It's more difficult to find A2s and their 110 MH/s on MRR these days, and the average rental is in the 500 MH/s range and there are some 1 and 1.5 GH rigs available. We have to keep this new environment in mind as we work toward 9.4.0.
One of the things we've been discussing is the amount of energy required to maintain a POW coin. That's one of the biggest reasons we've been looking at hybrid systems. That being said, no system is free from manipulation. CPU-only algos can be abused by botnets. POS can be manipulated, though it's apparently only slightly less secure than POW overall. Everything has a risk/reward process. We were born a 10 minute scrypt coin with the intent of being BTC in Scrypt. We've done our best to stay with that with every decision we've made. Today, though, we see that BTC's very slow and we don't want to repeat all of the challenges they've gone through.
Something I'd like to ask the community to think about is what you think about mining energy, and resilience and resistance to network disruption if the power goes down. Should we follow in BTC's footsteps and work to keep from having the trouble they've had as they scale? Or should we strike out in another direction? Is TOR integration important to you? Is it important to be able to mine with a laptop? I guess I'm thinking about such things tonight as a category 3 hurricane is a couple of hundred miles away.
Something I'd like to ask the community to think about is what you think about mining energy, and resilience and resistance to network disruption if the power goes down. Should we follow in BTC's footsteps and work to keep from having the trouble they've had as they scale? Or should we strike out in another direction? Is TOR integration important to you? Is it important to be able to mine with a laptop? I guess I'm thinking about such things tonight as a category 3 hurricane is a couple of hundred miles away.
It is bullshit to attack PoW coin with timewrap. Only some PoS coins can be attacked for purpose get more PoS rate for himself.
In PoW used cumulative difficulty, and win chain with 30 blocks with Diff 100, than 59 blocks with diff 50.
I agree that manipulating blocks is BS. I agree this isn't a traditional time warp. Yes, we're aware of how chains are scored. As I keep saying - this is simply some idiot exploiting a hole that's been in POW coins since BTC hit the streets in order to take block rewards and manipulate the difficulty. We've known about the possibility of this for years. Frankly, it's a weakness of all POW coins. The universal cure is hash rate, which is why we're happy to see more miners on the coin as our value continues to increase.In PoW used cumulative difficulty, and win chain with 30 blocks with Diff 100, than 59 blocks with diff 50.
It is bullshit to attack PoW coin with timewrap. Only some PoS coins can be attacked for purpose get more PoS rate for himself.
In PoW used cumulative difficulty, and win chain with 30 blocks with Diff 100, than 59 blocks with diff 50.
In PoW used cumulative difficulty, and win chain with 30 blocks with Diff 100, than 59 blocks with diff 50.
When I testing latest Novacoin code (test my new coin), I found that first new block on next day, have yesterday's timestamp. Wallet was working all time, miner was started next day again.
This isn't the thread for Novacoin, which has been around since 2013 and isn't a new coin. Please stick to the rules of the forum.We've been watching the blocks since 2014 and have been exploring them more deeply recently as Blak builds a new type of block explorer. We've had forks, we've had plenty of fast mining, and this is the first time-manipulation attack we've seen reflected in block times. We understand what the code should be doing, what it's actually doing, and how 9bU7p5PooXMhequCNWSJQCbaw8sgHp4Ekd is able to manipulate block headers. While this is new for us (and frankly, it's a compliment as it verifies that CAT's valuable and is expected to continue to grow!) it's not new for crypto.
We've had Art Forz' time warp code in our codebase since we launched in 2013, so this isn't a timewarp.
https://bitcointalksearch.org/topic/blocking-the-time-warp-attack-114751
I'll leave this as it is for a bit, as I'm going to get back to work on 9.4.0, and also to prepare for a hurricane.
When I testing latest Novacoin code (test my new coin), I found that first new block on next day, have yesterday's timestamp. Wallet was working all time, miner was started next day again.
We're removing the smartchain.cc block explorer from the OP and community lists because we cannot contact them to update their code.
If they contact us, or if we see that they've updated, we'll gladly add them to the list once again.
The official community explorer at catcoinwallets.com is already updated. The explorer run by prohashing isn't yet updated but they've acknowledged they have our code in the queue.
If they contact us, or if we see that they've updated, we'll gladly add them to the list once again.
The official community explorer at catcoinwallets.com is already updated. The explorer run by prohashing isn't yet updated but they've acknowledged they have our code in the queue.
This is conspiracy theory!
All block time that mined from pool (stratum) update block time periodically.
If someone use home ASIC with getwork protocol and no new transactions added, then new block created for miner
right after receive last block and time not changed until next block found or added transaction.
You may check, that all timewrap blocks have only 50 CAT reward without any transactions.
You might want to check the code and see how many different clocks are used to make sure block timestamps are sane. The local miner's computer clock isn't the only clock, and isn't even the primary clock.All block time that mined from pool (stratum) update block time periodically.
If someone use home ASIC with getwork protocol and no new transactions added, then new block created for miner
right after receive last block and time not changed until next block found or added transaction.
You may check, that all timewrap blocks have only 50 CAT reward without any transactions.
No, Vampirus, this isn't a 'conspiracy theory' - check the data and check the code - they don't lie.
From util.cpp:
Quote
//
// "Never go to sea with two chronometers; take one or three."
// Our three time sources are:
// - System clock
// - Median of other nodes clocks
// - The user (asking the user to fix the system clock if the first two disagree)
//
// "Never go to sea with two chronometers; take one or three."
// Our three time sources are:
// - System clock
// - Median of other nodes clocks
// - The user (asking the user to fix the system clock if the first two disagree)
//
We've had plenty of low-diff periods with sub-1 second blocks and they've all come in with proper block time order. The code is continually updating the block's timestamp prior to release as the block is being built. Going back in time is suspect. Submitting blocks with only the coinbase transaction when there are TXns on the network is the definition of a selfish miner. Combining the two is an exploit.
This is conspiracy theory!
All block time that mined from pool (stratum) update block time periodically.
If someone use home ASIC with getwork protocol and no new transactions added, then new block created for miner
right after receive last block and time not changed until next block found or added transaction.
You may check, that all timewrap blocks have only 50 CAT reward without any transactions.
All block time that mined from pool (stratum) update block time periodically.
If someone use home ASIC with getwork protocol and no new transactions added, then new block created for miner
right after receive last block and time not changed until next block found or added transaction.
You may check, that all timewrap blocks have only 50 CAT reward without any transactions.
Greetings CATs! It's not Caturday but I'm feeling like an update and hope y'all are, too. If not, go away - it'll be here when you're ready. 
- So...we have this new code on the streets. Everyone critical has updated. The last two entities that we're still waiting on are the two additional block explorers - the one maintained by Prohashing and the one maintained by smartchain.cc. Prohashing did acknowledge that new code exists, so that's a plus.
- BTW - we've been pinging the folks that have made us Mac wallets in the past but it seems they're no longer in the compiling business. We're looking for leads - anyone up for compiling a 9.3.0 CAT wallet? Yes, there's a reward.
We had a few updates on testnet for more than a year but didn't want to release another wallet right away after 9.2.0 was released because frankly CAT's had so many wallets and forks in her life that we really wanted to just give her time to run a bit. What put us over the edge, decision wise, was that the new interest in CAT and our new life on the exchange brought at least one miner/hacker that likes CAT but doesn't want to buy or mine them, preferring to steal them. That wouldn't cause much stress by itself as any POW coin should expect selfish miners from time to time. But this one decided to exploit a hole in the code that wasn't properly vetting blocks. As some of you know, CAT was forked from LTC back in 2013. We've updated our codebase over the years to include advancements in the code, but unlike BTC and LTC with their significant mining base, a 'nuisance bug' for them is more critical for us. If you've been watching the block chart at catcoinwallets you will have noticed that about the same time our price started to climb, some of our block times got long again, and our difficulty jumped up from our normal 120-ish range to the 200s, then 300s, and now 400 range. Sometimes that's from more miners on the network - we've had up to 3 GH/s (!) of hashing for 6 to 8 hours. So some of the higher difficulty time has been from mining and that's normal and fantastic! But there's also this:
The output from the CatChain explorer shows us that something's not right. Block 117459 has a block time of 13:32:15 and 117460 has a block time of 13:31:41. Clearly 460 wasn't solved prior to 459. The code, though, does allow some range of block times in order to make up for network latency and for clocks to be a bit off. If we just look at that information, we might agree with Vampirus' earlier suggestion that it's just a simple clock problem. One thing about the CAT team, though, is that we like plenty of data sources and we like to cross-check them. Let's look at the output of the bot running 24/7 on Freenode IRC/#catcoin (everyone wave to jaboja when he goes by!):
Unlike the explorer, the bot gives us the (absolute value of the) block time as reported inside the block, but also gives us a UTC time hack. We can see that 117459 was solved around 08:32 UTC and that 117460 was accepted by the network at about 11:14 UTC. That's a healthy 2 hour and 42 second block. But the block time calculation shows a 34 second block time! Yeah, something's broken.
Finally, let's check the output of the chart that lives on catcoinwallets:
The last line at around 400 represents our time sitting on block 117460 waiting to solve 117461's 538 difficulty. The line prior to that, at just under 500 difficulty, represents the time we spent at 117459 (about 2 1/2 hours, more or less). The block prior to that is the approximately 1 hour we spent at 117458 before finding 459.
What we've got is someone building blocks - very often with only the 50 CAT block payout - that is also manipulating the block time. Sometimes blocks are in proper time order, sometimes blocks are reported to arrive prior to the parent block, and sometimes after a multi-hour wait a block arrives with an ridiculously small block time. And in POW code, the block times are used to calculate the change in difficulty.
In a textbook time-warp attack, the attacker wants to doctor the times to reduce the difficulty so they can mine more blocks. I don't think our attacker is mining, though, so they benefit from keeping our diff higher than it should be - it keeps legit miners from solving blocks and gives them plenty of time to build their next bogus block. I think you'll all agree that we have data to confirm that this isn't a simple system time error.
In nine days, when 9.3.0 activates (1st September at 00:00 UTC), blocks that arrive marked earlier in time will fail.
- Finally, we want to report that CAT's PID difficulty adjustment started a trend in crypto! After much work, we implemented a PID adjust process in 9.1.0 back in March of 2014 - the first coin in the ecosystem that brought in an industrial control system. Because this was in the early and very chaotic days for CAT, we needed to field an almost emergency wallet and didn't have time to implement all of the options we wanted - like more refined settings that eased dips, and the ability for the network to automatically reduce the difficulty if a block ran too long. We went with what we had and it's been the core tech that's kept us moving for almost four years. As we wait for 9.3.0 to take effect and begin work on 9.4.0, we found that another set of coindevs took up the PID challenge, and created an evolution of our PID and implemented the 'long block auto-drop' process we hoped to do back in 2014. It appears it's running in at least AnonCoin. If you're interested, there's some good nerd stuff below. Yes, we're reaching out to compare notes with them, and we're happy that CAT's a leader!
https://github.com/zcash/zcash/issues/998
https://wiki.anoncoin.net/GroundRod_PID_main_ver2
So CATs - too many words again, but hopefully it's useful info. Miners - thanks for mining! Traders - thanks for trading and enjoy the volatility! And CATs - thanks for being here and for telling your friends!
Andy
- So...we have this new code on the streets. Everyone critical has updated. The last two entities that we're still waiting on are the two additional block explorers - the one maintained by Prohashing and the one maintained by smartchain.cc. Prohashing did acknowledge that new code exists, so that's a plus.
- BTW - we've been pinging the folks that have made us Mac wallets in the past but it seems they're no longer in the compiling business. We're looking for leads - anyone up for compiling a 9.3.0 CAT wallet? Yes, there's a reward.
We had a few updates on testnet for more than a year but didn't want to release another wallet right away after 9.2.0 was released because frankly CAT's had so many wallets and forks in her life that we really wanted to just give her time to run a bit. What put us over the edge, decision wise, was that the new interest in CAT and our new life on the exchange brought at least one miner/hacker that likes CAT but doesn't want to buy or mine them, preferring to steal them. That wouldn't cause much stress by itself as any POW coin should expect selfish miners from time to time. But this one decided to exploit a hole in the code that wasn't properly vetting blocks. As some of you know, CAT was forked from LTC back in 2013. We've updated our codebase over the years to include advancements in the code, but unlike BTC and LTC with their significant mining base, a 'nuisance bug' for them is more critical for us. If you've been watching the block chart at catcoinwallets you will have noticed that about the same time our price started to climb, some of our block times got long again, and our difficulty jumped up from our normal 120-ish range to the 200s, then 300s, and now 400 range. Sometimes that's from more miners on the network - we've had up to 3 GH/s (!) of hashing for 6 to 8 hours. So some of the higher difficulty time has been from mining and that's normal and fantastic! But there's also this:
The output from the CatChain explorer shows us that something's not right. Block 117459 has a block time of 13:32:15 and 117460 has a block time of 13:31:41. Clearly 460 wasn't solved prior to 459. The code, though, does allow some range of block times in order to make up for network latency and for clocks to be a bit off. If we just look at that information, we might agree with Vampirus' earlier suggestion that it's just a simple clock problem. One thing about the CAT team, though, is that we like plenty of data sources and we like to cross-check them. Let's look at the output of the bot running 24/7 on Freenode IRC/#catcoin (everyone wave to jaboja when he goes by!):
Unlike the explorer, the bot gives us the (absolute value of the) block time as reported inside the block, but also gives us a UTC time hack. We can see that 117459 was solved around 08:32 UTC and that 117460 was accepted by the network at about 11:14 UTC. That's a healthy 2 hour and 42 second block. But the block time calculation shows a 34 second block time! Yeah, something's broken.
Finally, let's check the output of the chart that lives on catcoinwallets:
The last line at around 400 represents our time sitting on block 117460 waiting to solve 117461's 538 difficulty. The line prior to that, at just under 500 difficulty, represents the time we spent at 117459 (about 2 1/2 hours, more or less). The block prior to that is the approximately 1 hour we spent at 117458 before finding 459.
What we've got is someone building blocks - very often with only the 50 CAT block payout - that is also manipulating the block time. Sometimes blocks are in proper time order, sometimes blocks are reported to arrive prior to the parent block, and sometimes after a multi-hour wait a block arrives with an ridiculously small block time. And in POW code, the block times are used to calculate the change in difficulty.
In a textbook time-warp attack, the attacker wants to doctor the times to reduce the difficulty so they can mine more blocks. I don't think our attacker is mining, though, so they benefit from keeping our diff higher than it should be - it keeps legit miners from solving blocks and gives them plenty of time to build their next bogus block. I think you'll all agree that we have data to confirm that this isn't a simple system time error.
In nine days, when 9.3.0 activates (1st September at 00:00 UTC), blocks that arrive marked earlier in time will fail.
- Finally, we want to report that CAT's PID difficulty adjustment started a trend in crypto! After much work, we implemented a PID adjust process in 9.1.0 back in March of 2014 - the first coin in the ecosystem that brought in an industrial control system. Because this was in the early and very chaotic days for CAT, we needed to field an almost emergency wallet and didn't have time to implement all of the options we wanted - like more refined settings that eased dips, and the ability for the network to automatically reduce the difficulty if a block ran too long. We went with what we had and it's been the core tech that's kept us moving for almost four years. As we wait for 9.3.0 to take effect and begin work on 9.4.0, we found that another set of coindevs took up the PID challenge, and created an evolution of our PID and implemented the 'long block auto-drop' process we hoped to do back in 2014. It appears it's running in at least AnonCoin. If you're interested, there's some good nerd stuff below. Yes, we're reaching out to compare notes with them, and we're happy that CAT's a leader!
https://github.com/zcash/zcash/issues/998
https://wiki.anoncoin.net/GroundRod_PID_main_ver2
So CATs - too many words again, but hopefully it's useful info. Miners - thanks for mining! Traders - thanks for trading and enjoy the volatility! And CATs - thanks for being here and for telling your friends!
Andy
Hi all. help!!! restored the old wallet. In this the entire amount is not confirmed... what to do?
xordi - please tell us what version wallet you restored, and how you restored it. We'll see if we can help. May be better create voting pool and ask users: go to PoS or stay on PoW?
Thanks for your input. As I've already said, POS is no longer on the table. Please review my earlier updates as we've laid out the plan for CAT - which does include surveying the community.
May be better create voting pool and ask users: go to PoS or stay on PoW?
Hi all. help!!! restored the old wallet. In this the entire amount is not confirmed... what to do?
Why do you think that checkpoint server is centralization, but hardcoded checkpoints from developer not centralization?
I never said it wasn't, did I?Can you not see, however, that a few checkpoints in code in order to navigate previous forks allows community consensus (something I believe you've found yourself on the wrong side of at one point) while a separate server feeding a constant checkpoint update does not allow consensus? Can you see the very distinct differences in centralization?
Now when all know about this attack, no one sell his old empty wallet.
Those are nice words, yet the exploit has been known and people still sell their addresses, don't they?As I've already expressed, there are too may problems with POS - including centralization, favoring whales over the rest of community, and various attack vectors - and we have taken it off the table. Do what you want with your project. CAT's not going there.
Why do you think that checkpoint server is centralization, but hardcoded checkpoints from developer not centralization?
Now when all know about this attack, no one sell his old empty wallet.
This attack only can be for some PoS coins, not for PoS+PoW or high difficulty PoS as Hyperstake.
Now when all know about this attack, no one sell his old empty wallet.
This attack only can be for some PoS coins, not for PoS+PoW or high difficulty PoS as Hyperstake.
See my new SCIFI coin https://bitcointalksearch.org/topic/ann-united-scifi-coin-scifi-powpos-2092094 that protected from any PoS attack.
1 - max time drift 3 min
2 - max maturity 30 days - prevent from accumulate big stake weight in one wallet
3 - checkpoint server with 8 block fixation - attacker can't insert blockchain more then 8 last blocks
4 - Balanced PoW blocks and stakes weighting - best calculation of BlockTrust.
PS. with latest change in code you only create additional vulnerability for attacker. I can create my server and with lower rate get all blocks,
and any others from official servers will be rejected. Because limit for future time drift must be as past time drift.
A checkpoint server such as this is a centralized control mechanism. That is not in harmony with the decentralized goal of crypto as defined by Nakamoto. That's part of our challenge - the goal is to improve the breed of fully decentralized coins, not move closer to FIAT, and not to provide a POS 'private club' that serves whales and leaves everyone else on the sidelines.1 - max time drift 3 min
2 - max maturity 30 days - prevent from accumulate big stake weight in one wallet
3 - checkpoint server with 8 block fixation - attacker can't insert blockchain more then 8 last blocks
4 - Balanced PoW blocks and stakes weighting - best calculation of BlockTrust.
PS. with latest change in code you only create additional vulnerability for attacker. I can create my server and with lower rate get all blocks,
and any others from official servers will be rejected. Because limit for future time drift must be as past time drift.
Anyone attacking a small coin with manufactured blocks can move the difficulty and control block formation. There is no mining-related reason for our difficulty to be in the 300-400 range - this is all attack. That's a known weakness in all POW coinage. People are still hitting BTC and LTC with those methods. Instead of fixing the problem, the BTC devs ignore it because they think they're too large to take over. There was an effort by a past member of the CAT dev team to take tighter, centralized, control of the blockchain and that was soundly rejected by the community and the rest of the team. We're not going down that path again.
I'll take a look at your new coin - thanks for the heads up.
Edited to add: Check this thread: https://bitcointalksearch.org/topic/proof-that-proof-of-stake-is-either-extremely-vulnerable-or-totally-centralised-1382241
See my new SCIFI coin https://bitcointalksearch.org/topic/ann-united-scifi-coin-scifi-powpos-2092094 that protected from any PoS attack.
1 - max time drift 3 min
2 - max maturity 30 days - prevent from accumulate big stake weight in one wallet
3 - checkpoint server with 8 block fixation - attacker can't insert blockchain more then 8 last blocks
4 - Balanced PoW blocks and stakes weighting - best calculation of BlockTrust.
PS. with latest change in code you only create additional vulnerability for attacker. I can create my server and with lower rate get all blocks,
and any others from official servers will be rejected. Because limit for future time drift must be as past time drift.
1 - max time drift 3 min
2 - max maturity 30 days - prevent from accumulate big stake weight in one wallet
3 - checkpoint server with 8 block fixation - attacker can't insert blockchain more then 8 last blocks
4 - Balanced PoW blocks and stakes weighting - best calculation of BlockTrust.
PS. with latest change in code you only create additional vulnerability for attacker. I can create my server and with lower rate get all blocks,
and any others from official servers will be rejected. Because limit for future time drift must be as past time drift.
For PoW coin attacker just rent hash on miningrigrentals, for PoS coin attacker must buy 50% of coins and wait 30-90 days, then attack his own coin (because he biggest investor) and can't stay anonymous.
CAT not attacked, because only on one exchange with low liquidity.
I can easy attack CAT, but I biggest investor (15%) and want to be protected from other attack. If you want I may say in privat how it works, but for attack need 2 exchange with high liquidity.
You're not the biggest investor of CAT if you have 15%, though that is a significant stake.CAT not attacked, because only on one exchange with low liquidity.
I can easy attack CAT, but I biggest investor (15%) and want to be protected from other attack. If you want I may say in privat how it works, but for attack need 2 exchange with high liquidity.
There are a number of different types of attacks one can do to to POS. One of them only requires about 15% of the coinbase. Another requires buying old addresses. There are a couple of recent protocols but I've not yet seen them used in coins so don't know how well (or if) they work. Here's one example:
https://arxiv.org/abs/1601.00275
All of the POW coins have been attacked, and even the current BTC codebase can't stop various types of timewarp-type attacks. We are certain that what's been knocking us around the past 6 or so weeks isn't just a time error because we have a selfish miner (not an attack per se) that sometimes submits blocks in time sequence and sometimes doesn't, and that also sometimes submits blocks with errors. We have plenty of experience with the effects of profit switching - I've been mining CAT since launch in 2013.
Anyway... the time warps should be a thing of the past on the 1st. We can't stop selfish miners as long as they're submitting valid blocks, and we can't stop profit-switching (and frankly, don't want to).
We're pulling some code together for testnet to see if we can adjust PID to get rid of the dips. We're looking at the security of a couple of CPU-only POW processes, as well as POW/POS hybrids. We don't have a guess when 9.4.0 will be ready but will keep everyone informed.
Jump to: