2 ms·
> all of these can essentially require transparency + encryption (i.e. git + signatures), not the whole blockchain, That's just empirically not true. You need
by darawk 8y ago
> all of these can essentially require transparency + encryption (i.e. git + signatures), not the whole blockchain,
That's just empirically not true. You need to timestamp transactions in a BFT way for all those examples. No way around it.
> hence can be had without the huge energy losses (that come from many nodes (re-)computing the same result over and over, and
You can get this with Proof of Stake. But you do need a BFT timestamping mechanism.
> centralisation is a feature most people want, because it helps resolve conflicts (à la Vitalik's centralised resolution of the DAO conflict).
Citation needed. Centralization has upsides and downsides. It will take time to figure out how to do decentralization well.
- tomp 8y ago> You need to timestamp transactions No, for most things what you really need is a happens before relationship. Git does that better, since it supports multiple timelines (branches) that can be resolved (merged) cleanly if there are no conflicts (double spends).
- darawk 8y ago> if there are no conflicts (double spends). What about when there are, though?
- hannasanarion 8y agoThen let the person that everyone agrees to be an authority (the project owner) decide, not the person who happens to own the most GPUs.
- darawk 8y agoThat's a model that's totally great for open source projects. Not so much for currencies, or stock trading.
- madeofpalk 8y agoHow is this any different from a government or central bank?
- tomp 8y agoMerge doesn't happen, participants resolve the issue or raise a conflict with the central authority. Same as with Ethereum :D
- madeofpalk 8y ago> It will take time to figure out how to do decentralization well. How long do we have to wait to find how to do decentralization well? It's been 10 years now and we're still asking the same question.