Hitler Gregory had moved it from the original thread where it belonged in context, and he renamed the thread to this adhominen insult name, OT crap from Compact Confidential Transactions for Bitcoin.
What is so ironic is that I think I ended up later potentially solving the proof-of-square requirement (required by the flaw Andrew Poelstra aka andytoshi has discovered) for Compact Confidential Transactions (CCT) when I merged that homomorphic encryption with Cryptonote ring signatures prior to the similar attempt to merge Blockstream's less efficient CT with Cryptonote.
https://bitcointalksearch.org/topic/m.5640949
Lol, you linked to where I had been the first one to point out to Gregory Maxwell, that CoinJoin can always be jammed with DoS because one can't blacklist the attacker because the entire point of CoinJoin is to provide mixing so that an attacker can obscure his UTXO history.
You are so careless that you didn't even realize that was my famous shaming of Gregory. Did you miss the post where I declared "checkmate" then Gregory responded with ad hominem and then by the force of my correct logic he had to STFU.
Lol, again you missed where at the end I showed the math derivation of how to defeat selfish-mining which was the basic idea behind published designs such as GHOST (which I wasn't aware at the time and only became aware of when I read Vitalik's blog).
You linked to a guy who is technologically ignorant and is currently a BU shill.
Yes Gregory did point an error in my conceptualization of Winternitz which I had only become aware of just hours or days before that, and I admitted it. I even went on to write Winternitz code and become quite expert on it, even incorporating Winternitz it into my anti-DDoS conceptualization.
But you failed to cite the other occasions where I put Gregory's foot in his mouth, such as my recent expose on how Bitmain checkmated Blockstream and in 2016 I pointed out that his flawed logic and math on why Ogg shouldn't have index (which was a format in which he was intimately involved as a co-designer of one of the key compression codes!):
Also I don't understand how you calculate 20% increase in file size for adding an index. For example, lets take an average 180 second song consuming roughly 5MB for VBR encoding. Let's assume my users are satisfied with seeking in 1 second increments, so that means means I need at most 180 of 22-bit indices, so that is only 495 bytes which is only a 0.01% increase! On top of that I could even compress those 22-bit indices into relative offsets if I want to shrink it by roughly 75% to 0.0025%.
Ah that reminds me why @stereotype keeps trolling my threads, again, and again and continuing to be habitually incorrect.
Mate, change those drugs youre currently taking for your TB. If they are not the cause of your desperate ramblings, think about making an appointment with another doctor. Seriously.