undefined | Better HN

0 pointsnullc10y ago0 comments

> are public

Ah. What mechanism assures this consistency of this information?

> at one node might or might not be a problem

How could it not be a problem? If that is the totality of the network, and the network is 1-fault tolerant, what prevents spontaneous divergence of the state?

> most likely cause of such a topology is a Sybil attack

"likely"? It's not clear what you mean there. What statistical model have you adopted that allows you to reason about the likelihood of various topologies?

Social networks usually appear to have small word behavior where its usually very easy to draw lines that describe disjoint local-majorities (or fairly large local-super-majorities).

I agree that a sybil sticking on a bunch on a bunch of extra 'nodes' and the sybil nodes diverging as a result isn't interesting case. What I do think is interesting is what mechanism will prevent user's honestly stated trust (much less politically manipulated trust) being a bad topology?

What is the procedure that I can follow, that if everyone else follows it, results in the correct global behavior (with high probability)? What are the additional assumptions required to achieve that and make it secure? Why are they plausible? Do they provide decentralization? (I can suggest on procedure which works: Stellar tells everyone who to trust; but it completely fails at decentralization so I assume that isn't the goal.)

In Bitcoin our security assumption is that the computational majority of participants conform to the protocol ('are honest') and these participants are not completely partitioned from each other. People can then think about-- or debate-- how reasonable those assumptions are.

(There are alternative formulations of Bitcoin's security which also argue about how plausible these assumptions are given economic incentive assumptions; but even this most simple set of assumptions gives people something easy to reason about.)

Can you give a parallel (informally stated, but equally comprehensive) version of the security assumptions for your consensus system?

> But there is certainly precedent for building a robust network out of pairwise relationships, namely inter-domain routing on the Internet.

The Internet is _wildly_ inconsistent. Asymmetric routing is the norm, the internet frequently suffers small partitioning and loops; single malicious parties at the edge can frequently inject bad state that is accepted globally, congestion and blocking happens multiple hops away from users where they have no recourse. The internet is not a consensus system, and these issues are not usually hugely problematic; someones brokenness doesn't involve your traffic generally effect you, you can route around problems locally. Ephemeral routing and ledgers are fairly different problems. Ambiguity about the ownership of a coin eventually effects almost everyone. I'm not seeing the connection you're making there.

I certainly agree that useful systems can be built from pairwise relationships: The original ripple design for pure IOUs without creating its own cryptocurrency prior to opencoin buying the ripple name was such a system, it had no need for a global consensus (except perhaps in certain atomic unwind cases)-- only the participants in a particular IOu transfer needed to be involved. It is not at all clear to me that a safe global consensus system can be built from pairwise trust.

0 comments

mazieres10y ago

At it's core, the question of whom to trust is of course crucial, as there are clearly at least straw-man answers that have undesirable effects. But the trust topology affects more than safety, it affects the scenarios in which a consensus protocol is useful. E.g., if I issue some scrip and trade it on the Stellar network, I don't necessarily want to depend on mining rigs in other parts of the world for my ledger safety. I want to tell people "trust whomever you want, but be sure to include me as well, because I won't let you redeem the scrip if you don't have it on my ledger."

Part of the goal of SCP is to leave such policy questions up to the market and see what kind of architecture emerges. Our hope is that this flexibility combined with the lower barrier to entry will lead to greater financial inclusion as people build on our platform. But if we add too many policy restrictions, we risk heading off unanticipated innovations. (Heck, someone might literally replicate the Bitcoin policy and configure their quorum slices to trust 67% of whoever mined a Bitcoin block in the past week. That wouldn't really make sense, but it's possible.)

That said, what you're getting at is that with flexibility comes risk. We can't a priori rule out the possibility that organizations will choose bad quorum slices that violate safety. But we need to ask under what circumstances people care about safety and why. People obviously won't care about forks if one of the branches is purely a Sybil attack. But they likely will care if "real organizations" diverge, for some notion of that term. The reason, again, is that at some point the "real organizations" will affect one another in the network, however indirectly--maybe after a chain of five payments. That kind of indirect link is precisely what FBA quorums capture in the transitive closure of slices. So if everyone depends on the financial institutions they expect to do business with, and the whole economy is in fact interconnected, then Stellar will be safe.

I obviously believe such interdependence exists, and fully expect Stellar to be safe, but I can't predict exactly what the network will look like. Nor do I want to, as this could limit innovation. Only time will tell how this plays out.

nullcOP10y ago

> I don't necessarily want to depend on mining rigs

Indeed, the security model provided by Bitcoin consensus system may not be fit for any particular purpose. But it has one, and so we can think about it and decide what purposes it may or may not be fit for, and think about under what conditions it will be safe or not safe.

> is to leave such policy questions up to the market and see what kind of architecture emerges

Users of a system take actions. In your system, it seems, the collective actions of all the users result in an effective security model. You refer to this as leaving it up to the market.

The resulting security model--the conditions of success or failure, the invariants which must hold--may be unknown to any of its participants; it may be even unknowable to any one human mind. It may, and almost certainly will, change over time. A user adopts the system today, but finds tomorrow that it is behaving in a way which was previously impossible, including restrictions being sprung on them later--the possibility of which is a kind of restriction in and of itself.

> Heck, someone might literally replicate the Bitcoin policy and configure their quorum slices to trust 67% of whoever mined a Bitcoin block[1] in the past week.

Even your best outcomes with pinning the state to "real organizations" leave me wanting to cite Jo Freeman's "The Tyranny of Structurelessness" as a source for concerns--but I can't, because by failing to state a specific security model, you have a fully general defense against any attack or failure mode: "okay, don't take that risk, the invisible pink hand can choose another set of tradeoffs instead". As you've helpfully demonstrated above (by claiming to generalize the Bitcoin consensus model), there is no conceivable attack for which you couldn't say the system addresses it, as the security is basically external. In some sense you might as well have just shipped a C compiler, pointed out that it was fully general for whatever the market might choose to do (good or bad), and said it was up to the market.

[[1]As an aside, Bitcoin mining is not just creating identities via hashcash; Blocks commit to the past ledger state-- it's effectively a signature itself--, and this is integral to the security model; without that those identities could concurrently create unbounded conflicting states with constant energy usage. See, https://download.wpsoftware.net/bitcoin/pos.pdf for a more complete discussion of the subtle details around that.]

For a market to choose, there must be a choice and there must be intent and understanding. Participants need to be able to trust that their choices are effective and won't be completely undermined by the choices of others, or at least understand how their choices might be undermined and be confident enough that such an outcome is unlikely. For the market to choose, people would need to understand the global ramifications of their actions and the actions of others, but you've seemingly provided no tools to reason about these.

I'm not complaining that there is risk--there is that aplenty, and in Bitcoin too for sure--but that there is no commitment to a sufficiently complete concrete security model at all, which makes the risk impossible to assess. Bitcoin users will also sometime make arguments about the suicide pact of the interconnected economy, but they do that as an answer to what if the first plausible mechanism fails. It probably okay that a system has generality and can potentially fullly accommodate the whim of man, but the more our systems rest on that the more opaque they are in practice.

I really think Stellar should develop and transparently state specific technical 'plan' on how the system should be used-- how trust should be configured globally-- and defend the plausibility and desirability of that model, describe who will and won't have the power to control the system as a result, how centralized it will be, how people can choose to configure their own systems to bring about that outcome, and how we can tell if it has achieved a configuration which can deliver on that plan (preferably before observing a failure). Maybe even multiple such plans, if it were possible to analyze their interactions.

Without that, I can't shake the impression that what you're actually saying isn't 'leave it up to the market' but that instead what you're actually saying is 'leave it up to chance'.

vbuterin10y ago

You're saying "how do we know that that quora will sufficiently overlap?". David seems to be saying "how do we know they won't?". At this point, I think just about everyone can agree that the security depends on a set of empirical assumptions that we currently simply do not know how they will play out into the real world. So my plan at least is to simply sit back and see how it actually ends up evolving in real life; if it fails, the Stellar Foundation was centralized enough to temporarily take back the reins for itself the last time, so I don't see why it can't do it again.

That said, my _prediction_ is that it will work fine mostly, occasionally there will be concerns about people splitting off into islands, and a resulting second-order consequence is that people will start putting the Stellar equivalent of blockchain.info onto their trust list in order to ensure connectivity to the "main graph" (I had actually cited The Tyranny of Structurelessness in my own responses already :) ), and this will just have to be the social-network-consensus version of the GHash.io scare and we'll be fighting against people's private interests to be lazy to reduce the risk of that happening.

1 more reply

nbouscal10y ago

I'm out of my league here technically, but I'm having a hard time seeing how your critiques don't apply to the entire market economy just as well.

The collective actions of all participants result in an effective price model, the causes of which are unknown to any of its participants and likely unknowable to any one human mind, and which changes over time in ways that are highly opaque.

In the market at large, participants certainly don't need to understand the global ramifications of their actions, only the local ones. I don't see why that isn't the case here as well.

(For what it's worth I want to point out that like Walter, I really enjoyed reading this discussion, even if much of it is over my head.)

2 more replies

contingencies10y ago

Walter from Kraken here - I really enjoyed this thread!

(Bit sleep-deprived right now but) FWIW, here's my take: Bitcoin tries to be too many things to too many people. Original ripple was a great response, though without providing a strong solution to the topology problem (manual processes for trust agility).

Now, both fail to "do one thing and do it well". Fundamentally, the functions 'settlement protocol', 'currency' and 'client program' (ie. implementation of protocol) should be well delimited. Besides these, Bitcoin now effectively attempts to do more (expensive paid public sequential datastore and agent-based computing platform, ill-conceived invoicing system, future revenue-guarantees for early adopters/special nodes, etc.)

This brings me to some points I feel have not been considered in this thread: (1) People don't put absolute trust in a settlement network or currency. The de-facto means of managing risk is to simply to limit exposure: either by sending smaller amounts sequentially over time and validating delivery with your endpoint (out of band) prior to sending the next 'chunk'; or by splitting a transaction across multiple currencies/settlement networks/(anonymous/temporary/unpredictable) points of network connectivity. (2) No system fits all people. It's great that the stellar notion addresses one of Bitcoin's most glaring issues: latency for real time / retail transactions. However, it does not necessarily meet all of Bitcoin's capabilities, nor should it aim to. A real world user should have a computationally available means of comparing these networks against real time requirements to select an appropriate path (in terms of risk mitigation strategy, temporal requirements, maximum transaction size limitations, secrecy requirements, and any other execution and routing goals/preferences). (3/corollary) The key issue in present-era financial systems may be that business logic around the true properties of a financial transaction, network or settlement partner are very rarely formally defined (ie. typically many pages of indecipherable legalese that amount to 'we promise nothing and have well paid lawyers', with no computationally usable community metric for SLA enforcement on latency, reliability, instances of failure, etc.)

My thoughts here have remained fairly constant for the last four years: what is really needed is a business-level transaction protocol that disclaims any affinity at all for (a) the currency or currencies in a transaction; (b) the settlement systems used; (c) the endpoint identification system used; (d) allows the discussion/agreement of a realistic range of resolution strategies for common problems in business-level transactions; and (e) facilitates flexible (indeed, multi-path) routing between endpoints across arbitrary financial service providers, potentially using multi-hop/multi-asset pathways shortlisted in real-time through actor and transaction-specific requirements.

A valid settlement path should be 'buy expensive art, get on a plane, deliver to mansion'. Likewise, a valid settlement path should be 'plant a tree and share the GPS location and have it manually validated by a third party'. (These are outlying examples, but an example of the degree of flexibility that should be aimed for in the long tail of latency and use cases. The shorter side is obvious: redundant multi-provider fiscal routing (even across conventional banks), level playing field for emergent financial systems and the conventional ones, etc.)

Some time ago I tried to make proposals in this area at http://ifex-project.org/ (IIBAN perhaps most successfully) but have not been able to dedicate much time to the notion lately. I do however feel it is relevant and am willing to jump at any time to work with others to move the notion forward. If you two are interested I'd love to get together and bash something formal and extensible out of this line of thinking. Tentative proposal: meeting in Europe next month?

j / k navigate · click thread line to collapse