Because the person mining the block can decide what transactions can be in it, he can just fork off the main branch and undo transactions... The whole point of a 51% attack. So even if he couldn't get his hand on 5 CPID's which is trivially easy.
So the goal of the attacker isn't to get those coins, it's the goal of the attacker to race the main branch so they can un do transactions and thus double spend their coins. I know very well what a 51% attack is thank you very much.
Further more shuffeling around transactions every 250 hashes isn't a limitation, it's merely a simple shuffle attackers could easily create just 100 transactions each block to shuffle around a bit, thus changing the outcoming hash (even without being able to change the nonce).
I don't know why I'm even arguing with you either, it's not like you're going to listen. Maybe you should ask a security expert about this stuff, I would be dumbfounded if there's any security expert willing to go on record saying that this is even remotely safe for a crypto currency.
Unfortunately you havent proven anything new here, and most of this is incorrect.
A 51% attack would require more than 51% of the CPIDs, that was the statement I wanted you to make and you didnt. Its literally impossible.
They cant fork off to another branch because of setbestchain, no client will follow that branch.
You discount the hardness to maintain a CPID with RAC. Its not easy, try it, it takes a full node 1 day of work to get enough rac to be in the block.
Shuffling 250 transactions, Im sorry, wrong terminology, not possible, not related to what is in our code. We deliberately only have left two fields in the getblockhash that can change the hash: nonce and timestamp. Timestamp has an allowable window of 5 minutes in either direction from getadjustedtime, meaning we only allow 300 values (in seconds). Nonce is limited (CheckNonce()) to 250 HPS globally. You cannot submit a block to our network with a nonce > 251 for a block that is less than 61 seconds old. Transactions have nothing to do with it. This is indeed a security feature, and affects the conversation by 90%. This alone + DGW prevents a 51% attack. Were basically allow 99% of the hashes to pass through biblepay with no effect when they exceed the noncelimit. To discount this effect to zero would be like ignoring the cornerstone of the building, its absolutely relevant as part of the base calculation for a 51% attack.
Regarding security expert, I am still working with Martin, but any real security expert is invited to take a look at the POW code, Im confident we are much more secure than the average POW implementation with the CPID restriction and the nonce limit in place, but this person will have to admit the weaknesses inherent in POW in the first place and make an honest comparison, not one that is biased towards removing the credibility for the other facets of PODC. I admitted where the risks were in PODC, and Im basically telling everyone, we know the SQL database inside Rosetta is the weak point. Lets find a way to create a tamperproof pill bottle for it, and make it more reliable. I continue to say, I would rather live with Rosettas quirks than the current bitcoin status quo where 93% of the heat miners are now hogging the rewards and we have no control over upgrades. Its a disaster, whereas PODCs environment is quite favorable.