Re: Do you think "iamnotback" really has the" Bitcoin killer"?
It is important for me to clear up the record on the following because I am preparing to blog on a ToE which ties in everything we've been discussing lately. 
Re: OT crap from Compact Confidential Transactions for Bitcoin
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.
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!):
Ah that reminds me why @stereotype keeps trolling my threads, again, and again and continuing to be habitually incorrect.
Edit2: Thanks for the move, totally appropriate.
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.
Andrew Poelstra and Gregory Maxwell don't need any defense by me, their records stand on their own, but I'm thinking pointing this out may be helpful to those that aren't familiar with your antics. I'll also point out that most people, especially GMaxwell have been overwhelmingly patient with you.
https://bitcointalk.org/index.php?topic=279249.msg5640949#msg5640949
https://bitcointalk.org/index.php?topic=279249.msg5640949#msg5640949
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!):
And how is not having the index any worse than not allowing an index. I fail to see the logic. Seems you are arguing that the receiving end will expect indexes and not be prepared for the case where indexes are not present. But that is a bug in the receiving end's software then. And in that case, there is no assurance that software would have done the index-less seeking more efficiently for the status quo of not allowing an index. None of this makes sense to me.
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%.
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.