W3C home > Mailing lists > Public > public-webpayments@w3.org > September 2012

Re: Payments and Trust

From: Amir Taaki <zgenjix@yahoo.com>
Date: Sun, 23 Sep 2012 11:59:21 -0700 (PDT)
Message-ID: <1348426761.46393.YahooMailNeo@web121002.mail.ne1.yahoo.com>
To: "public-webpayments@w3.org" <public-webpayments@w3.org>
Interesting generalisation of a common structure in payments systems. I like the idea that we can begin classifying different systems in terms of the sets of overlays that they encompass.

For instance, you classify Ripple as the set that contains 2 overlays for credit and debits, whereas PGP is 2 overlays for validated identites and assessments of diligence. In the Ripple set, all the overlays have their behaviour encoded in them, whereas with PGP, it is up to me to decide whether to trust another person's assessment of someone's identity. We could say that overlay relies more on social involvement rather than being an implicit encoding of that system.

Thinking in general terms allows us to look for commonalities between these very different systems. However I'd caution about over-generalising. I think a lot of this stuff is poorly defined. We don't really know what works and what doesn't. It's a soft science.

It's as if we have a bag of tricks. Slashdot has its effective karma system, Stack Overflow has awards and KickStarter has reward tiers. If you examine how these tricks interact with each other, then it's hard to figure out why they produce the emergent behaviour that they do.

eBay does not have a weblike structure. But maybe that's what works for eBay. It could be because the effectiveness drops off extremely fast after 1 hop from your node. It could also be that in these complex systems where their behaviour is subject to environmental and other forms of pressure, that it's hard to truly predict or anticipate their outcome. I think many of these services function according to the community that's built up around them, when they developed and the kind of environment they came into.

So we can examine existing systems to try to draw conclusions from them.

One such system I find interesting is CouchSurfing. There is a normal network of references. The way this works is that each person gets left references (positive, neutral, negative). You get a graph built up (as you described) of trust between people.


The implicit assumption here is that more references = more trustworthy people. In CouchSurfing, the emphasis is placed more on the quantity of assessments (or experiences) rather than the quality of them. The main purpose of this system is to protect people against very bad people, not to assess the quality of a person's character (that's done through the actual profile). This is an example of where I mentioned above, that a particular form of pressure or constraint on the system has changed how it is setup or ends up functioning (the early versions of CouchSurfing were much simpler in scope and evolved towards the current setup).

Of course people can now use sock-puppet accounts to try and game the network. But that's why in CouchSurfing you have a) vouching (prominent CouchSurfers can vouch for trusted people) b) a distinct friends network and c) a visualisation of the hops from your account to another person's account through your mutual friends (only when logged in).

The way these random tricks interact with each other is kind of ad-hoc, but it's an example of a system that's been setup initially and then optimised towards a functioning state.

Another thing is that with trust networks, we always try to give the power of analysis to the user rather than getting them to trust abstract analysis. This social issue might make it difficult to construct powerful trust networks.

If we did use abstract analysis more, then I think bayesian analysis needs to be the first choice. Simple bayesian inference can be used to make good guesses about something like the ability of a person to adequately be depended upon in a trust network, given several indicators about that person.

Another powerful tool is using statistical tools like z-testing. However the danger is falling into the trap of selecting for expected behaviour because it's the norm and thereby causing it to become the expected behaviour.

Anyway the purpose of this rant is that if we use trust networks for payments, then you better be sure that your trust network is pretty fucking solid. If it can be gamed, then people will put in insane hours to do it for $1 or less. I like the idea of thinking about them in terms of sets of overlays, but I feel like perhaps there might be more to this story. Perhaps there is a way to describe the relationships between overlays in a set. Or maybe the way nodes in this directed graph weight the trust values that aggregate along them.

From: Andrew Miller <amiller@cs.ucf.edu>
To: Melvin Carvalho <melvincarvalho@gmail.com> 
Cc: Web Payments <public-webpayments@w3.org> 
Sent: Sunday, September 23, 2012 5:40 PM
Subject: Re: Payments and Trust

The relationship between Trust, the Web, and Payments is profound and
deep, and Ripple is the clearest expression of this idea. The
important thing to realize is that trust is inherently a weblike
structure. Trust is subjective and indirect. I'm going to describe the
general structure of the social graph, and explain how you get
different forms by choosing the semantics of the edges.

Consider a family of directed weighted graphs sharing the same nodes,
where each node represents a persona - either a 'real identity' or a
pseudonym. Since the graphs share the same nodes, they differ only by
the edges. So by a 'family of graphs', I mean that each graph is like
an overlay of links between the same set of nodes. In each case, an
edge between a pair of personas represents some kind of direct
relationship between the two. Given one of these graphs, and a pair of
nodes/personas, what we are usually interested is observing a 'flow'
of some kind, the sum of all weighted paths from A to B.

In one overlay, each edge represents a credit line, where the weight
is the credit limit. The flow from one person to another represents
the total available credit to use as a payment. In another overlay,
each edge represents an 'outstanding balance', or a debt - credit
limits that have been exercised. These two overlays together are
Ripple, which allows payment through indirect credit on a web. Also
see "Liquidity in Credit Networks" http://arxiv.org/abs/1007.0515

In another overlay, each edge represents that one person has
diligently validated the identity of another. In another overlay, each
edge represents an assessment that a persona is trustworthy to perform
such diligent checks. These two overlays together are the PGP web of
trust, which is useful for validating identities with no central

In a slight variation of this, the edges represent trust in the
responsible trading behavior of each person. Now we are talking about
a reputation graph like Bitcoin-OTC. For an illustration, see

In another overlay, each edge represents an 'insurance bond' where one
person vouches for the other. The flow from A to B represents the
amount of insurance payout that A could collect if B misbehaves. This
graph is TrustDavis.

Do you see that these are all inherently the same kind of weblike
structure? It's disappointing that OpenTabs, for example, scopes
itself out of the potential to express indirect relationships, since
the credits are strictly limited to the two people who initially
interacted with each other. As another example, eBay has a seller
reputation, but it is global rather than weblike, and therefore also
cannot express indirect trust. Bicoin-OTC is weblike, eBay ratings are
not. Ripple is weblike, OpenTabs is not. Let us build more weblike

On Sun, Sep 23, 2012 at 8:28 AM, Melvin Carvalho
<melvincarvalho@gmail.com> wrote:
> I'm starting to think more and more that payments and trust go hand in hand.
> This is especially true when you are establishing credit limits for issuing
> new money.
> Has anyone had thoughts on this topic?

Andrew Miller
Received on Sunday, 23 September 2012 18:59:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:07:21 UTC