Opus5/low can do CryptoNote base58 decoding toolless, in working memory alone
1–8 of 8 posts
Re: Opus5/low can do CryptoNote base58 decoding toolless, in working memory alone
#2Can it handle rot13 too?
Re: Opus5/low can do CryptoNote base58 decoding toolless, in working memory alone
#3Re: Opus5/low can do CryptoNote base58 decoding toolless, in working memory alone
#4Well I would hope so. That's the most basic "translation" a computer can do. Converting one set of characters into another set of characters from a lookup table. How many r's in strawberry is a more difficult question. Can it handle rot13 too?
Re: Opus5/low can do CryptoNote base58 decoding toolless, in working memory alone
#5Well I would hope so. That's the most basic "translation" a computer can do. Converting one set of characters into another set of characters from a lookup table. How many r's in strawberry is a more difficult question. Can it handle rot13 too?
Re: Opus5/low can do CryptoNote base58 decoding toolless, in working memory alone
#6Well I would hope so. That's the most basic "translation" a computer can do. Converting one set of characters into another set of characters from a lookup table. How many r's in strawberry is a more difficult question. Can it handle rot13 too?
I don't think you understand how this variant of base58 works.
Or here: https://bitcoinwiki.org/wiki/base58
Is this some unique baseXX encoding? Please educate me. You do know that just because bitcoin uses it doesn't make it special, and doesn't stop it from being the second most basic translation task? The most basic being something like rot13 (direct character substitution). Are you saying this is somehow special because extra characters are added at the end to make the "grammar" work?
Re: Opus5/low can do CryptoNote base58 decoding toolless, in working memory alone
#7Earlier quoted context omitted.
I don't think you understand how this variant of base58 works.
Oh. I assumed it was the same baseXX encoding with padding as any other. As listed here: https://en.wikipedia.org/wiki/Binary-to-text_encoding#Exampl... Or here: https://bitcoinwiki.org/wiki/base58 Is this some unique baseXX encoding? Please educate me. You do know that just because bitcoin uses it doesn't make it special, and doesn't stop it from being the second most basic translation task? The most basic being som…
It makes it not a straight 1:1 map unlike b64, and you need to be doing actual compute in order to get to the result. You are operating on blocks and calculating checks on each, etc. The algorithm isn’t complicated by any means but it’s certainly not the “second most basic translation task”.
And the CryptoNote variant is further different as it operates on 8 byte blocks. So you linked the wrong documentation.
Re: Opus5/low can do CryptoNote base58 decoding toolless, in working memory alone
#8Earlier quoted context omitted.
Oh. I assumed it was the same baseXX encoding with padding as any other. As listed here: https://en.wikipedia.org/wiki/Binary-to-text_encoding#Exampl... Or here: https://bitcoinwiki.org/wiki/base58 Is this some unique baseXX encoding? Please educate me. You do know that just because bitcoin uses it doesn't make it special, and doesn't stop it from being the second most basic translation task? The most basic being som…
Sigh. Read your own link? Yes it’s not the same baseXX encoding with padding as any other. It makes it not a straight 1:1 map unlike b64, and you need to be doing actual compute in order to get to the result. You are operating on blocks and calculating checks on each, etc. The algorithm isn’t complicated by any means but it’s certainly not the “second most basic translation task”. And the CryptoNote variant is furthe…
You are correct in that I didn't catch the "CryptoNote" variant. But a different block size? Come on. That's not even a material difference. This shit still isn't magic.
But you're right that it is more on the order of "how many r's in strawberry" difficult than it being less difficult.
There's still not some big magic difference between modification per block and modification at the end. It's still right up the alley of a translation machine.
I stand by it being the second most difficult translation task.
And I stand by the original post being goofy hype.