Orphanes. 51% problem

[xiphon]

First, to reproduce that your hashrate need to be as tenths of percents of total network hashrate (even with 20-30% you will have good chances to reproduce).

1. Sync blockchain with the network
2. Stop receiving blockchain updates from the network (this can be done manually or by mistake or by bad connection etc.)
3. Mine continuous bunch of blocks (2, 3 .. 10 how much you want)
4. At the timepoint when you see that your personal blockchain is higher than network blockchain start announcing to other nodes that you are having bigger block index than they have
5. Other nodes will download your blockchain making original blockchain orphaned
6. Now you are replaced ("injected") your blocks

So it is basically the same 51% problem.

I don't think that anyone had produced that situation deliberately. Miners that were able to do that had to have really big hashrate and a bad connection (?) (or some other sync issues) was more than enough.

As for timestamps that are equal to previous block's timestamp. Inspected the code. Forging blocks having the same timestamp as previous block will lead to difficulty increase more roughly. So no profit here at all.

[PascalCoinDev]

Please note that "more work" wins over "more high" blockchain (Introduced on PascalCoin 1.5)

How PascalCoin calcs "more work".

• Each block has a "target_compact" value, that is calculated on previous blocks timestamp
• Work = SUM(target_compact)
• The target_compact of block 100 is the SAME for a legit timestamp and for a malformed timestamp. (timestamp is not used for calc work on current block, will be used for NEXT block)
• The target_compact of block 101 will be calculated based on timestamp of block 100: If block 100 was with a lower timestamp, the result will be HIGH compact_target value (more work for block 101). If block 100 was with a higher timestamp, the result will be LOWER compact_target value (less work for block 101)

Then, note that a node will accept as a valid the first new block received and will discard the other ones (malformeds or legits), so:

• If 2 blocks have the same number, but diff time, the first send will be the used by other nodes. (will not check the timestamp value, only will check that >= last valid timestamp and <=+180 seconds current node timestamp
• To inject a block, you need to generate 2 blocks: 1 to be injected and the next one. That means MORE WORK
• If you inject a block, but you used a future timestamp of block 100 (low work), then you're exposed that legit miners found a block to re-inject with higher work than previously injected block. Always win MORE WORK.

The personal conclusion is that to inject a block you need more work, and that cannot be solved if a miner has 51% of the hashrate

[xiphon]

@PascalCoin, thanks for your reply.

So, updating code to "more work" logic from PascalCoin 1.5 may help with that crazy orphane rates.

[xiphon]

@PascalCoin,
have analyzed

"more work" wins over "more high"

a bit.
It seems to me that that models are the same by their nature, so nothing will change. Have i missed something?

[xiphon]

Updated first post and renamed the issue because this actually not a block's timestamp problem.

[adaseb]

The timestamp issue still can be a problem and exist. When the coin first launched, some "cheaters" hosted a few nodes on their own. They moved the time ahead on those nodes so the average timestamp would be further ahead, then they moved their miner PCs time up to 30-60 seconds or so and no other miners blocks would get accepted because they got the "invalid timestamp error".

Nobody does this cheat anymore because the block times are much further apart and moving the clock up 30-60 seconds had little effect but the issue is still present.

For the other minor issues such as difficulty retarget they can be easily tighten by changing the factor here

{ Important: Note that a -500 is the same that divide by 2 (-100%), and
1000 is the same that multiply by 2 (+100%), so we limit increase
in a limit [-500..+1000] for a complete (CT_CalcNewTargetBlocksAverage DIV 2) round }
if CT_CalcNewTargetBlocksAverage>1 then begin
factor1000Min := (-500) DIV (CT_CalcNewTargetBlocksAverage DIV 2);
factor1000Max := (1000) DIV (CT_CalcNewTargetBlocksAverage DIV 2);
end else begin
factor1000Min := (-500);
factor1000Max := (1000);
end;

[xiphon]

Created separate issue #2 for that.

[adaseb]

Seems somebody on the PascalCoin Github opened a similar ticket

PascalCoin#25