4 ms·
The "chaining one hash of a JSON file into the next one" makes me wonder if this system could be implemented on top of a DVCS, which is _also_ maintaining a tre
by al2o3cr 4y ago
The "chaining one hash of a JSON file into the next one" makes me wonder if this system could be implemented on top of a DVCS, which is _also_ maintaining a tree of changes to files connected by hashes.
Some other things that jump out on a first read:
* seems like any entity that controls 500m + 1 units of value can make themselves block producer (by voting out anyone else) and can't ever be removed (because they control a majority). Until the project achieves significant uptake, the creator of the protocol is that entity; instant rug-pull potential.
* signatures would prevent a producer's compromised Twitter account from maliciously updating the ledger, but seems like an attacker could freeze up the network for at least one cycle
* the current producer's signing keys are a bug-bounty piñata
- sov0_custodian 4y agoThanks, great points. - Hadn't thought about DVCS, but yes this mechanism of chaining hashes is there. - On majority ownership: correct, this is an issue with excess centralization, which is an issue for blockchains in general. The remedy in this case is the standard one: the community would have to coordinate on forking out the misbehaving party. - On rug pull: we're not going to sell the tokens to a general audience (for legal reasons among other things). But you're correct that there needs to be a community around the asset (and thus as sufficient level of decentralization) before it can serve its purpose of being a coordinated value store. - On compromising twitter: you're correct that the inclusion of the signature makes it so that a compromised twitter doesn't compromise updates, could lead to freeze. The mitigation here would be coordination on backup broadcast accounts. - On signing key issues: would love to hear more of your thoughts on this, thank you!