I have started on fixing the difficulty adjustment. It amazes me that both bitcoin and litecoin and many other early coins have no defences against a very wide variance in hashpower over time. Once a block comes in at a very high difficulty, the only time it adjusts the difficulty down is when another block, which must be as high as the previous one according to the difficulty. Essentially it averages the last 10, but it can only bump the difficulty up by 2% each time a new block comes in so the attacker can just show up for 5-10 minutes a day, bomb the chain with blocks, and know that likely at least 3 hours before anyone else on the network might find a solution as high as the difficulty has got. I think this is known as the 'instamine' problem.

So, I have been busy searching through the code, following the execution path from starting, and located the place where difficulty is adjusted and where I can potentially add a timer triggered event that I set to exactly 5 minutes, and then it sets a new one for every minute afterwards, that recalculates and propagates a difficulty change.

The other measure I think is required is to massively accelerate the rate at which difficulty rises in response to blocks less than 1 minute apart. These adjustments really should go up fast, I think 4% at the second block in 10 seconds, and each subsequent block less than a minute apart the difficulty adjustment doubles, so next block under 1 minute pushes the difficulty up 8%, the 4th will trigger 16%, 5th at 32%. This should at least slow the second block to the root of the interval between (so if it was 4 seconds between the next will be likely at least 16, after that 256, and then by this time we are at close to a normal block period).

This adjusts to the massive jump in hashpower quickly, and then after that the previous timer triggered event will lower the difficulty by 2% every minute past 5 minutes time. It should lower to actual available hashpower within 20-30 minutes which will be long enough to at least double if not quadruple the cost of this attacker compared to their profit. They would need to keep mining at least for half an hour to get more than 3 or 4 blocks, and they don't even seem to hang around longer than about 5 minutes. This makes sense since this is the averaging period and after 20 blocks it has risen by 1.02^10 at least, 21% higher, but the longer the gap the more likely the chain is to adjust downwards.

Essentially the chain doesn't currently have a strategy to deal with a sharp decrease in block time and this means that the target is woefully incorrect most of the time. When being attacked, it isn't high enough, when the attack is over, it has no way to adjust back to normal hashpower.

In fact, another measure could be an option, to simply disallow any block arriving less than 1 minute since the previous. This should not be based on the block timestamp, but instead simply the accept block function can be set to reject anything sooner than 60 seconds since the last and just drop the block. This might be even simpler to implement than adding a timer triggered event. All the necessary variables are already in scope where I would add it. There is absolutely no benefit to blocks arriving closer than 30 seconds anyway, and one minute is a reasonable minimum.

The process by which servers in a distributed network decide what to accept and what to reject has a built in subjectivity. The transactions do not propagate instantly to all nodes at once, every node has a different memory pool, most of the time, to any other, at any given moment in time. By disallowing a subjective 1 minute time limit after a block that any block arriving before 60 seconds after the last was received, we are not trusting the timestamps on the blocks, which can be post-dated by some period (I think with bitcoin it's an hour either way), but rather just how the blocks propagate. If a block comes in close to this boundary, it may be that say 25% of the nodes reject the block if it arrived sooner for them than the previous arrived, the block will still succeed because most nodes didn't see it until after they saw the previous one.

Anyway, I need to set some agenda items here in the Lab, hopefully I will see the boss soon.

https://github.com/gamecredits-project/GameCredits/releases/tag/0.15.2

New GameCredits 0.15.2 release is available
Please update your QT wallets

Formal announcement from the team will come in the next 24-48 hours.

Hi Rick,

Glad to see more people show interest in ParallelCoin

https://join.slack.com/t/parallelcoin/shared_invite/enQtMzYzOTU5OTc0NzkwLTZhZWRmZDUyYjUxNzJkM2UxYjJkODM3Mjk2ODJkNjk1M2E4ZDM5NTkxMTZjODdmMjljNDE2MTkwM2FjMTg3YmM

The new dev joined today the team... his name is l0k1.
He will be doing the update of DUO wallet and fix latest security issues (and more).
 
Join Parallelcoin on Slack to see latest developments and news:
https://parallelcoin.slack.com

How many coins can be mined?

Is this project paying now? I read here the comments for the past year and did not understand. Thank you.

I would always go for hardware wallet. I know most people might have seen it as not being the best, but the truth is , every bitcoin storing method has its own disadvantages and also their advantages. Paper wallet is good, but there is a tendency of easily getting destroyed. Hardware wallet is good also but the idea of been tampered by a third party gave it away negatively.  What I suggest you should do is to reset it upon arrival before you use it.

In my last talk with Marcetin a few days ago he did also tell me the same... He is coding all the time, pretty much 24*7, not getting much sleep, working on getting things finished. Hats off for all the work he is doing.

I already saw some of his work he has done, so I can tell it is true. Also soon I will be able to test finished things and report final errors to him, if there are any.

Ledger Nano S has long been known to have software vulnerabilities. I also touched on this topic. I wonder how the producer wants to sell a wallet that does not give much security ...

I know what Marcetin do all this time.

He sleep in office, literaly. He don't want do to lose time.