[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