It's not for avoiding looks-similar-to-a-human chars like Base58. It's for QR codes. The alphabet is exactly the alphabet for Alphanumeric mode QR codes.
A 40-L code allows 4296 characters in Alphanumeric-mode = 2864 bytes after Base45 decoding.
The same code allows 2953 characters in Byte mode. If you use Byte mode to hold Base64, that's 2214 bytes after decoding, so Base45 is more efficient.
The reason it gives for why you can't use Byte mode to directly hold binary data is
> Even in Byte mode a typical QR-code reader tries to interpret a byte sequence as an UTF-8 or ISO/IEC 8859-1 encoded text. Thus QR-codes cannot be used to encode arbitrary binary data directly.
It also says you're not supposed to use it anywhere but QR codes (like URLs)
> If the data is to be sent via some other transport [not stored in a QR-code], a transport encoding suitable for that transport should be used instead of Base45. It is not recommended to first encode data in Base45 and then encode the resulting string in for example Base64 if the data is to be sent via email. Instead the Base45 encoding should be removed, and the data itself should be encoded in Base64.
Worse, if the overall Ethereum community reaches a consensus that a malicious entity attempted to take over the network, then the devs will fork the blockchain to rollback the particular transactions with the malicious entity, and the new blockchain will keep chugging along as normal while the attacker has just lost a shitton of dollars to buy 100BB. (This is similar to what happened with the DAO previously, although the reason for it was bugs rather than a 51% attack)
This is not what happened with the DAO. This is well documented and I suggest you read up on. TLDR, the hacker tried to withdraw the funds and there was a 30 day lockup period so the contract was updated to stop this.
My understanding was that an illicit fund withdrawing was possible because of a bug in the contract code (more specifically a recursive call loophole), and the community executed a hard fork to return those funds to their original owners. I’m curious as to what I’m misunderstanding here.
Hi, Daniel here.
About a year ago, I made this algorithm called EventReduce. It is able to optimize database queries that run multiple times (aka Realtime-Queries or Live-Queries).
Before making EventReduce, I scouted over about 2 years if something like this already exists but couldnt find something similar other then MongoDBs OPLOG_DRIVER.
After finishing EventReduce last year I added it to my little side project database, RxDB[1] where it is sucessfully in use over the last year.
Also I already made a hackernews post [2] with mixed comments about how this can work and when this is usefull.
So now I am here again with the goal to get some feedback of people who try out EventReduce on top of their database.