OT crap from Compact Confidential Transactions for Bitcoin

[TPTB_need_war]

I'm sorry your thread was so badly derailed as to be basically unreadable.

This egotistical shit isn't going to help you.

Without an expert on cryptographic hashes commenting here on the possible breakage, I don't think you can claim omniscience.

As I explained in private, the output of a Random Oracle is assumed to have no topological structure, i.e. just random points in any multi-dimensional space you choose. We don't have to have a preimage of the solution in order to potentially have a multi-dimensional curvepartial-order appear due to structure found in the hash function and be able to reduce the entropy. I understand that even Cryptonote has the same reliance on a Random Oracle to prevent undetected inflation. Thus I also understand that concern about hash functions may be out-of-scope of discussing or orthogonal to the innovations of this paper. My point was essentially wouldn't it be safer to use a 256-bit curve.

Recommendations are for 256-bit ECC  and hash security to be protected until 2032:

http://www.keylength.com/en/compare/

Heck after I opinioned that his original sum of two squares was lacking entropy, johoe proceeded to prove my intuition was correct.

As for the other idea I introduced about combining mixing (e.g. CN) and two curves, I was attempting to brainstorm simplifications. I asked 3 times whether it was possible to find multiple uncommitted values that could map to the same committed value, which I understood my idea hinged on. When I finally got the answer from Mixles, I dropped that idea.

Actually guys like me who toy around with simplifying ideas, in spite of not studying ECC extensively, sometimes do achieve simplifications.

So watch your ad hominem derogatory pompous mouth. Because you are going to eat the words you spout.

If you are Andrew Poelstra, I am about to make mincemeat of your whitepaper on PoS.

Narrow, unenlightened, closed-mindedness doesn't impress me. What impresses me are humble, open-minded, patient experts. Johoe appears to have this enviable quality.

[1714690687]

1714690687

[1714690687]

1714690687

[1714690687]

1714690687

[DumbFruit]

This egotistical shit isn't going to help you.

Here we go again... When I realized who you were I said to myself, "Oh, that explains a lot.", but I didn't mention anything hoping you'd just stop. Enough time and space was wasted. Here we are though, several pages later... You often follow this pattern;

1.) You vaguely complain about something, padding it out with technobabble.
2.) Get rebutted.
3.) Complain that the rebuttal was an ad-hominem.
4.) Repeat 1 through 3, often revolving around the same argument and rebuttal.
5.) Something else is fixed that sort of resembles your vague complaint.
6.) You claim great success because of this thing that was fixed.
7.) Nobody else sees this, because it didn't happen.
8.) You get exasperated and leave in a melodramatic fit.

Can we just skip to 8 and call it a day?

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=679743.0
https://bitcointalk.org/index.php?topic=600436.msg7872805#msg7872805

Edit: Relevant;
http://www.catb.org/esr/faqs/smart-questions.html

Edit2: Thanks for the move, totally appropriate.

[iamnotback]

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

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.

https://bitcointalk.org/index.php?topic=600436.msg7872805#msg7872805

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.

https://bitcointalk.org/index.php?topic=679743.0

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%.

Ah that reminds me why @stereotype keeps trolling my threads, again, and again and continuing to be habitually incorrect.

[stereotype]

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

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.

https://bitcointalk.org/index.php?topic=600436.msg7872805#msg7872805

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.

https://bitcointalk.org/index.php?topic=679743.0

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%.

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.