Open thekingbreaker opened 4 days ago
Statement from PKT.Net Foundation about alleged flaw in PacketCrypt: In the original code, the annHeader
is used to create an unique seed annHash0
, which is additionally used for each RandHash program. The seed can be changed by varying any of the parameters in the annHeader
along of hardNonce
, contentLength
, contentType
, or the contentHash
itself. The code that is alleging to uncover a flaw in the PacketCrypt algorithm keeps the hardNonce
static, but varies the seed by modifying the merkle root hash
instead of the header values. This is expected to generate valid announcements, because it makes them unique. It would be akin to keeping the hardNonce
static but randomizing the content fields. There is no performance gain to be expected from doing so, and there is no short-cut in mining using this approach. Further, the code presented as proof-of-concept, generates the 8192 items on-the-fly. This means that on a softNonce
width of 256k, and 3 items being dependant on the execution flow, there is at least 768k - 8k calculations done in excess, versus 8192 calculations in the original code. The conclusion is that this flaw is non-existant, the proof-of-concept merely demonstrates the possibility to alter various parts of the announcement as per the initial design. Furthermore, the proof-of-concept creates an at least the same amount of RandHash programs as the original code does, confirming that there is neither a flaw nor a demonstration of "fake announcements" or more efficient mining. Benchmarking shows that the proof-of-concept code is at least twice as slow as original mining code, which is consistent with the findings stated previously. We recommend dismissing this purported flaw as a disinformation campaign aimed at undermining confidence in the project.
Please stop focusing on the on-the-fly items. This was done to see if the worktarget at 32768 could be abused, by bailing out before softnonce max was reached. For low worktargets it is better to do the 8192 randhashes up front - just like packetcrypyt-rs does. You conveniently don't mention the main issue, so allow me to give a example. Using the original packetcrypt-rs code, imagine you do 10 getnextjob function calls. This means you have exhausted the softnonce max. By doing 10 getnextjob's you are performing 10 8192 randhashes (at hard round). Now imagine doing the same run but with my modified code. Now your getnextjob is only called ONCE, not 10 times i.e 1 8192 randhashes. So that is 81920 randhashes vs 8192 randhashes. The code provided does not take full advantage of this and there are further tricks I have thought of that can abuse this newly found flaw.
This is a paper claim, you simply moved what getNextJob does into the thread function, still called every time softNonce boundary lapses. So as it stands, the code submitted does not demonstrate any shortcuts, flaw or otherwise inconsistencies with initial algorithm design.
Incorrect the 'getnextjob' is called in the AnnMiner_start function, which is called every new block.
AnnMine.c line 321: A new randomized seed based on a modified merkle tree is used
AnnMine.c line 332: A new RandHash program is generated, as would be in getNextJob
AnnMine.c line 390: Each item is generated as accessed, which is even less efficient than doing upfront of the softNonce cycle.
All of this code is executed for each soft nonce round. Please indicate the lines of code that would demonstrate any kind of vulnerability.
It appears this is a major case of Dunning Kruger.
and you can't get your line numbers correct in the pastebin
1) Line 53 in Pastebin 2) Line 65 in Pastebin 3) Line 125 in Pastebin
The pastebin contains additional comments. It was clearly specified the line numbers are for AnnMine.c and not the quoted thread function.
You failed to show where 'getnextjob' is still thread based. Annminer.c line 324 and down is the soft round and irrelevant to my audit.
You are a serious investor and therefore biased person to be debating, please wait until Caleb or an outside coder can review.
Everything above line 324 does not do anything else than randomize the seed. The same could be accomplished by replacing the code above line 324 with randomizing the hardNonce or another header field.
It is absurdly clear you do not understand the code you have uploaded. Further, it is clear that there is no vulnerability.
Again, clear case of Dunning Kruger or trolling.
@cjdelisle unless you disagree, I believe the troll was given enough screen time to this point.
Caleb James DeLisle 12:26 PM
He's butthurt someone deleted his troll post off discord. But the thing is, posting "Major Security Issue With PKT" is likely to scare people who aren't technical and don't know it's a load of horseshit
for the record and investors, this issue has been archived ( https://archive.is/omqRd )
Thank you for archiving your libel and defamation.
and possible obfuscation
It is possible to create infinite merkle root hashes without performing randgen work (8192 items). Please see more details + source code demonstration
https://github.com/thekingbreaker/pkt-wedgie