3 ms·

> Care to link to sources for server-based and server-free decentralisation that aren't your own blog posts? The best precedent is simply the long-standing dif

by trentmc 10y ago

> Care to link to sources for server-based and server-free decentralisation that aren't your own blog posts? The best precedent is simply the long-standing difference between servers and clients in computing systems. In blockchain discourse, this difference had not been acknowledged as much; though of course a similar pattern exists between full nodes vs light/SPV clients. To my knowledge, no one else had made the clarification of "server-free" vs "server-less" as different types of decentralization. It is a useful distinction as the article discusses. > Also, that blog post you linked is flat out wrong -- Bitcoin, Ethereum, et al are all instances of eventually consistent systems As the article states, they can and do prevent double spends, so we agree there. But that's not what "consistent" means in a CAP setting. As the article states, "they they never have a deterministic guarantee of a consistent order; they’re only eventually consistent (in a probabilistic sense). But let’s be generous and call them consistent, because in practice they are used that way, the workaround being higher latency as one waits for a sufficiently high probability of avoiding inconsistency." > how do your nodes federate without a central authority? Each node votes on any transaction coming through. The transaction only clears if it gets enough positive votes. > just adapt a run of the mill distributed log-based db instead ... Well in some cases that's all that people actually need; sometimes find myself referring people to Kafka and the like. But Kafka and the like are still controlled by a single admin; you can do more to decentralize. As for immutability, it's all shades of grey, and certainly being a log-based db (read-only) helps a lot. You can do more with Merkle DAGs, continuous backup to write-only media, etc. To me it's not about "eroding" guarantees. It's about saying "ok, I have this database, what properties do I want?" The potential results might be blockchain-like or not. If decentralization, immutability, or assets are potentially interesting, then a blockchain technology could be interesting. Otherwise it comes down to other questions to choose among traditional DBs.

deleted 10y ago
[deleted]
pdpi 10y ago
> As the article states, they can and do prevent double spends, so we agree there. But that's not what "consistent" means in a CAP setting. You're the one who asserted that CAP-style consistency is required to prevent double-spends. Eventual consistency is a weakened form of consistency in the CAP sense. Both Bitcoin and Ethereum have eventual consistency as much more than a "theoretical" concern. In your own words: "But let’s be generous and call them consistent, because in practice they are used that way, the workaround being higher latency as one waits for a sufficiently high probability of avoiding inconsistency." The only way this is true is if you accept latencies measured in hours. For real-world applications, you absolutely need to deal with the eventual consistency (and, in fact, I've written several applications that deal with precisely that). > Each node votes on any transaction coming through. The transaction only clears if it gets enough positive votes. I didn't ask how you establish consensus. I asked how the nodes federate -- if a node tries to peer with you, how do you decide whether or not to accept the node? You suggested anonymity is out the window, so who controls node identity?
- trentmc 10y ago
  > You're the one who asserted that CAP-style consistency is required to prevent double-spends Could you point me to where? I like my thinking and expression to be consistent (pun intended:) > I asked how the nodes federate .. who controls identity? Each node has a list of the public keys of other nodes. There are various ways to handle key distribution, of course.
  - pdpi 10y ago
    From the blog post you linked three comments up or so: > Big “C” means all nodes see the same data at the same time. Being big-C consistent is a prerequisite to preventing double-spends, and therefore storing tokens of value. There are many models of consistency; we mean “consistent” in the same way that the CAP theorem does, except a little bit more loosely (for pragmatism). Little “c” means strong eventual consistency, such that when data gets merged there are no conflicts, but not consistent enough to prevent double spends. > there are various ways to handle key distribution, of course Right. Having the public keys advances the discussion precisely nothing, because public key auth is pretty much a given if we're talking about the servers identifying themselves. What tells us if we have a decentralised system with no central authority is: who's the gatekeeper? Who controls key distribution, and which keys are accepted into the pool?

by trentmc 10y ago

deleted 10y ago

[deleted]

pdpi 10y ago

> As the article states, they can and do prevent double spends, so we agree there. But that's not what "consistent" means in a CAP setting. You're the one who asserted that CAP-style consistency is required to prevent double-spends. Eventual consistency is a weakened form of consistency in the CAP sense. Both Bitcoin and Ethereum have eventual consistency as much more than a "theoretical" concern. In your own words: "But let’s be generous and call them consistent, because in practice they are used that way, the workaround being higher latency as one waits for a sufficiently high probability of avoiding inconsistency." The only way this is true is if you accept latencies measured in hours. For real-world applications, you absolutely need to deal with the eventual consistency (and, in fact, I've written several applications that deal with precisely that). > Each node votes on any transaction coming through. The transaction only clears if it gets enough positive votes. I didn't ask how you establish consensus. I asked how the nodes federate -- if a node tries to peer with you, how do you decide whether or not to accept the node? You suggested anonymity is out the window, so who controls node identity?

trentmc 10y ago
> You're the one who asserted that CAP-style consistency is required to prevent double-spends Could you point me to where? I like my thinking and expression to be consistent (pun intended:) > I asked how the nodes federate .. who controls identity? Each node has a list of the public keys of other nodes. There are various ways to handle key distribution, of course.
- pdpi 10y ago
  From the blog post you linked three comments up or so: > Big “C” means all nodes see the same data at the same time. Being big-C consistent is a prerequisite to preventing double-spends, and therefore storing tokens of value. There are many models of consistency; we mean “consistent” in the same way that the CAP theorem does, except a little bit more loosely (for pragmatism). Little “c” means strong eventual consistency, such that when data gets merged there are no conflicts, but not consistent enough to prevent double spends. > there are various ways to handle key distribution, of course Right. Having the public keys advances the discussion precisely nothing, because public key auth is pretty much a given if we're talking about the servers identifying themselves. What tells us if we have a decentralised system with no central authority is: who's the gatekeeper? Who controls key distribution, and which keys are accepted into the pool?