2 ms·
> 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
by 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 agoFrom 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?