[Cryptography] please help give advice on starting a project about 'trust'

ianG iang at iang.org
Mon Jan 26 08:56:52 EST 2015


On 26/01/2015 03:24 am, EyEs wrote:
> hi, :
>
> I am Zhu Li , and I am new here. I don't even know if it's suitable to
> post my request here, please excuse me if I bother any one.
> Since BitCoin paper is said to be post here for the first time. I am
> trying to see if I can start up a project about 'trust' with some advice
> from here.


First thing to understand is that 'trust' is a very difficult and 
essentially human word.  It does not translate to tech terms, and 
typically the word has been so destroyed in tech world that you'll never 
be able to have a sensible conversation about it.

So, try to replace 'trust' with something else.  Perhaps reliability of 
claims?  Security of investments?  Social standing?  Or, whenever you 
use the word trust, say this:  "Alice trusts Bob for WHAT?"


> My idea came out of this:
> In this world, we have billions of systems that collect user behaviours
> and analyze them and try to decide credit, and most of the system, is
> about money.
> In some nations, banks have already been exchanging data for years about
> peronal credit, like how they borrow money from banks, when and if they
> return the money, etc...
> In these systems, banks and personal customers are not equal, and bank
> systems have been a exclusive that other systems don't share data with
> them.


Yes, western financial world credit scoring.  It's not necessarily 
applicable everywhere, though.


> I now have a believe in such a system, which is open (both system and
> data are open), distributed over the internet, and every analyzation is
> based one user recommendation‍, and the 'users' are equally treated,
> though the user itself could be a person or an organizaion. and the
> system itself do not deal with any business, it only collects user
> credits from othres which may be with some kind of description. And the
> analyzations could be very dynamic, say in this system, not a One really
> decide the tags and weigh of tags, which decide the 'final credit',  and
> user collects there credit by others, and the credit may slowly fades
> out if the owner are burried in huge data, or some tags are no longer
> popular.


OK, so the claim you are trying to make over Bob is something like 
"Alice thinks Bob is worth X in credit" ?  Maybe it is more precise like 
"Alice agrees to extent Bob X in credit."


> Some questions about the design come to me, and as a freshman I strongly
> feel that I should have more to ask:
> . how to define and identify a user,


This is the crux of the bitcoin world's biggest problem.  It's the next 
frontier, IMHO, although few agree.  What follows is all my personal 
opinion, and do not assume I'm unbiased, as I've been involved and am 
involved in some things I mention below.



There is a long history in identifying users with cryptographic keys. 
OpenPGP and x.509 certificates are used in this fashion.  However these 
systems bungle the semantics (meaning) needed for actual use.  SPKI was 
also a system that went in this direction.  Although I know little about 
it, it appears to have at least explored the semantics issue more than 
the others.

What we can conclude from the above history is that an identity 
framework built from a key-centric vision is not adequate.

Then, in an alternate approach, CAcert the open CA, built an identity 
system based technologically on a LAMPS stack that records the KYC 
("know your customer") data, as typed in by a worldwide network of 
assurers.  Going beyond the traditional tech limits of the concept of 
identity, they added an arbitration layer which ensures robustness in 
claims:  assurers can be arbitrated against if they say the wrong thing. 
  They also added ways to communicate reliable claims albeit in simple 
non-tech terms.

What is probably clear from the CAcert experiment is that the tech stack 
they used wasn't adequate to reach human use cases either, but the 
semantic layer was much stronger and can IMHO support the use cases that 
people might come up with.


> . what basic elements should be considered in first time.


For a first time implementation?  For that I have no easy answer, if I 
did I'd build it :)  What I can say is that my current system has 
elements of all the things mentioned above.  It melds CAcert to keys and 
heads in the direction of SPKI semantics, and some new stuff.  It is 
quite complicated, big.

If you are a student looking to make a system in this area, I'd suggest 
you slice out only a part of the system.  The interesting space to me 
(?) would be semantics of claims.  If you can make a system that 
composes multiple claims together and the result is still parsable and 
interpretable to humans, that would be pretty good.  E.g., above Alice 
extends a line of credit to Bob.  What would your system do if Bob's 
other friends also do the same:  Carol, Dave, Eve.  If Bob can rely on 4 
lines of credit, can a statement be created that aggregates that into a 
single composed claim?

(By that I mean, leave out the crypto.  Making yet another key-centric 
id system might not work for you.)


> . how to determin the form of a 'recommendation‍', which makes everyone
> can check every record of a user and make a judge, to vote for it, or
> down-grade it.


This is part of the question of what I call semantics:  what is the 
claim that is made?  The problem consists loosely of many parts. 
Firstly you have to collect a claim.  Secondly, communicate it. 
Thirdly, parse it! which means by program and by human.  Next, compose 
it which means adding multiple claims together to make new claims.

Finally you have to test the claim;  what happens when the claim turns 
out to be unreliable?  This is the step that everyone typically bungles 
and therefore their system is unfounded, just a fantasy.

Only once you have all these elements in place do you start to see the 
concept of what we humans call trust emerge.


> . how to create a system of the dynamic tags, which really means
> something to users who visit this system.

Right, what are the claims that matter?

> . which kind of 'prove of work' or some other data exchange algorithem
> can help prevent cheating.

Irrelevant, don't assume a technical solution until you are much deeper 
into your design.


> . If a user (or many robots) come to make fake recommendations, how to
> downgrade there weight gently.


That's solved by your identity solution.  It isn't much of a solution if 
it cannot figure out sybils and forgeries :)


> . how to build such a distributed ‍system that could be stored and I
> think we may introduce a system the 'not all data should be collected as
> one so as to generate new blocks, which is neccessary in BitCoin system'

That also may be something you want to leave until later.  Measure the 
result against that requirement?



As I say, all the above is in my opinion.  I work directly in that area, 
for what it is worth.

iang


More information about the cryptography mailing list