[ARG] Re: [ZS] RESfest 2012 [F] : Alternative & Post-Economics reading materials

Mon Nov 5 11:58:33 PST 2012

On Mon, Nov 5, 2012 at 2:17 PM, Michael Hrenka <metahorse at gmail.com> wrote:

> Sounds good for short-time testing, but a permanent instance might be a
> bit expensive when compared to virtual servers.

In the EC2 it's likely that the bandwidth used will be the primary driver
of cost and not CPU power.  Here is an article I've written that covers
that ground:

https://drwho.virtadpt.net/archive/2012/03/11/tor-in-the-elastic-computing-cloud-fourteen-months-later

In short, as far as the EC2 is concerned bandwidth is bandwidth, regardless
of what it's used for.

> Yeah, but this opens up the danger that someone finds out your ID and can
> see all your transactions. I guess it's hard to avoid that danger in a
> reputation economy.
>

Depends on what your ID is.  For example, this is a Bitcoin public address
(used to send Bitcoins to whomever has the matching private key):
1Q7YCdDhzjxHf1CG2g4Akbq8EADPSzVYjj

However, for a social network a Bitcoin-like Id will never work thanks to
Zooko's Triangle (https://en.wikipedia.org/wiki/Zooko%27s_triangle), which
means that human readable IDs will be necessary.  So... practice good OPSEC
if you don't want people to know who a pseudonym corresponds to.  As for
reputation economies, reputation is attached to an identity (pseudonym or
otherwise) - as long as the entity presenting that identity is doing good
business with that identity, it doesn't really matter.  There are
cypherpunks and hackers out there who never came in from the cold (i.e.,
dropped their pseudonyms) and have a significant amount of social credit
attached to their handles.

Sybil prevention techniques based on the connectivity characteristics of
> social graphs can also limit the extent of damage that can be caused by a
> given sybil attacker while preserving anonymity, though these techniques
> cannot prevent sybil attacks entirely, and may be vulnerable to widespread
> small-scale sybil attacks. Examples of such prevention techniques are
> SybilGuard and the Advogato Trust Metric<https://en.wikipedia.org/wiki/Advogato#Trust_metric>
> .[4] <https://en.wikipedia.org/wiki/Sybil_attack#cite_note-3>
>

The part of the Wikipedia article you linked to describes a failure mode of
the Advogato Trust Metric, where someone claiming credentials that were not
earned managed to beat the system.  Perhaps Advogato isn't the right
solution.

> My Esteem Trust System uses short-range connectivity characteristics of
> the "Esteem Network". I'll need to take a look at other approaches to see
> whether they have significant advantages.
>

I'll reread your paper and see what else I can work out.

> That sounds like a useful idea. I guess implementing such a scheme would
> be quite useful in some situations. You could set up an account while
> several present and already trusted users verify the legitimacy of that
> newly created account. This nicely complements the mechanisms that I've
> come up with already.

There are a few problems with such a scheme, most of them having to do with
the amount of work a person has to do, as opposed to the amount of work
that the software has to do.

The "core group" (the folks who were there when something was done) have to
document what was done; people generally put off writing documentation
until the last minute when they absolutely have to.  So, people have to be
comfortable with writing up what was done and by whom, and applying
signatures to it prior to posting.  The software can hopefully automate the
digital signature bit, but the people have to do the writing.

Farther out from the "core group of foo", everyone who's one hop away has
to be prompted with a yay-or-nay to sign off on what happened.  It's easy
(and common) to just click "Ok" and get on with things, but that also means
that people can potentially sign off on things that haven't actually
happened.  Because verification of a writeup has to be done, laziness can
torpedo the system.

> My approach is to handle most of the Trust stuff by the automated and
> implicit Esteem Trust System. Everything else is a bonus. I guess I will
> have to make the Trust System so flexible that you can easily balance
> secure ID verification with user friendliness depending on how paranoid
> your targeted users are.

That would be a good thing.

> Where can I find these papers? A quick Google search didn't produce a lot
> of relevant results.
>

I'm doing some searching online and in my personal archive and I've found
references in Timothy C. May's _Crypto-Anarchist Manifesto_, Wavyhill and
Andre Goldman's DefCon 12 talk _Toward A Private Digital Economy_.  I have
a few more papers put away but I'll have to go through the last... 200 or
so hits in my search manually.

You may also find the paper _Distributed Marketplaces Using P2P Networks
and Public Key Cryptography_ by Signorini, Gulli, and Segre interesting.  I
can send you a copy if you like.

The paper _Implementation of P2P Reputation Management Using Distributed
Identities and Decentralized Recommendation Chains_ by Satheesh and Naresh
helpful.

_Formalizing and Securing Relationships on Public Networks_ by Nick Szabo
might be helpful (formalize.txt).

_The Cyphernomicon_, section 19.4.80 was where I first heard of reputation
networks.  Section 16.7 also has relevant information.

Reed S. Abbott's thesis _Closed Pseudonymous Groups_ will no doubt be of
interest.

If anyone wants copies of the documents I've found, I'll be happy to post
them.

Thanks for your ideas! I appreciate them. Do you want to be mentioned in
> the next version of the QP documentation?
>

If I was able to help somehow, I wouldn't mind being mentioned.

-- 
The Doctor [412/724/301/703] [ZS (MED)]
https://drwho.virtadpt.net/
"I am everywhere."

-- 
-- 
Zero State mailing list:
http://groups.google.com/group/DoctrineZero

----- End forwarded message -----
-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE