I was never into Ethereum, I didn't like the contract language's design (Was it soliloquy? It leads to buggy contracts). I didn't buy into the cult-of-personality of it's founder. I then really didn't like Ethereum and the people running it when they forked to save their own money in the Dao. I don't remember if the fork is ETC or ETH, but now that ETC has had a successful 51% attack against it I am even more not-for-Ethereum. It's a great theoretical advancement but NOT practically tractable.
And I say this as someone who did spend a lot of time implementing my own VM for executing Ethereum contracts so I could automatically detect which were vulnerable to bugs. But when the time came, I didn't run it since it didn't sit ethically right with me. I wouldn't want to surprise the contract's owner by taking all the Ethereum (HMMMM sounds familiar), and nor would I have a way to contact them.
So my stance on Ethereum are coming from actual hands-on experience too.
What's the best way to look into contact design for blockchain? I want to do collectible card games and other games with virtual asset collections that don't rely on the publisher to maintain a centralized database to be playable. It's not immediate future; my processes are massively pipelined
@AceNovo Sorry I didn't respond to this sooner. I looked into type theory a bit with contract design, as it seems very important to be able to fuzz or test every single state a smart contract can have and the operations on every such state (combinatorial explosion for complex contracts) at worst, and at best use some sort of theorem-like language that guarantees limits on inputs and outputs.
For example, early soliloquy community didn't realize bit-size issues with numbers. Not a fun problem to have.
@AceNovo But no I don't have any handy resources on me, it was something I "lightheartedly" got into (ie learn 60%, implement as much as I can, get bored and move on).
Thanks, that was helpful and I did say that I'm not on a deadline. 😎
You've given me some terms that will be useful for search later and confirmed my intuition that arbitrary barriers to creating hash collisions, like excluding binary data from records requiring a signature, would be useful features in a design
My general theory is that games can simulate asymmetric attention more quickly and evince better transparency characteristics than financial applications 😂
@cj the language's called Solidity, there are indeed some issues with it, but it's not that bad (and besides, there are other, e.g. Vyper that was designed to prevent all those problems). The fork, Ethereum Classic, is ETC & it is the one that got 51%-attacked. The "regular" Ethereum is fine.
This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!
Hosting costs are largely covered by our generous supporters on Patreon – thanks for all the help!