From: TrustBuckFella <TrustBuckFella@nowhere.com>
Date: Sat, 3 Aug 1996 17:43:45 +0800
To: cypherpunks@toad.com
Subject: TrustBucks
Message-ID: <64gf4trmj9@nowhere.com>
MIME-Version: 1.0
Content-Type: text/plain


-----BEGIN PGP SIGNED MESSAGE-----
 
An alternative model of electronic money.
 
Every model of electronic money I know of except one retains some degree
of centralization. There is always a central "mint", usually a bank. If
you can't find a bank that acts the way you want, you're SOL. And the
only thing that enforces non-abuse (inflation, etc) by the bank is the
equivalence of electronic money to some form of "real" money. The sole
exception is Digicash. Unfortunately, Digicash has no restraint on
infinite spending-into-debt.
 
I want to present an alternative model I call "TrustBucks". TrustBucks
is decentralized but zero-sum and needs no assistance from "real"
currency. Its central idea is a "web of trust": Local, trusted contacts
are linked in a web that at some remove can extend everywhere.
 
I'm not going to try to develop the cryptographic protocols for
TrustBucks. I haven't got the requisite paranoia and pickiness
(compliments both) for that. TrustBucks also has nothing in the way of
anonymity and restraint on double-spending right now. If you can see how
it could be anonymous or restrain double-spending and still work, please
feel free to add.
 
 
The basic rules of TrustBucks:
- -----------------------------------------------------------------
Each individual using TrustBucks has their own individual variety of
currency, notated here as TrustBucks( <name> ).
 
Each individual is considered to have an infinite supply of their
own TrustBucks.
 
Each individual accepts payment only in their own variety of TrustBucks.
 
There are only two fundamental operations with TrustBucks:
 
A and B swap TrustBucks, of any two varieties.
 
A pays B in TrustBucks( B ) for something external to the system.
 
 
- -----------------------------------------------------------------
 
Examples: Say Alice wants to pay Bob in TrustBucks, and Bob agreed to
accept payment in this form. Alice has several options for paying him.
 
*       Alice already has some TrustBucks( Bob ).
 
                Alice pays Bob.
 
*       The amount is small enough that Bob trusts Alice directly.
 
                Alice and Bob swap TrustBucks( Alice ) for TrustBucks( Bob )
                Alice pays Bob.
 
        I know this looks like an extra piece of complexity, but it's
        really not. By insisting that only TrustBucks( Bob ) are payment
        to Bob, we insure that Bob can't manipulate what currency he
        will accept to his advantage, which would otherwise be a
        problem. For instance, Bob cannot refuse to make good on his
        debts while accepting other people's money.
 
*       Alice doesn't have enough TrustBucks( Bob ), but does have
        TrustBucks( Carol ), and Bob trusts Carol directly for that
        amount.
 
                Alice and Bob swap TrustBucks( Carol ) for TrustBucks( Bob )
                Alice pays Bob.
 
*       Alice doesn't have enough TrustBucks( Bob ), but does have
        TrustBucks( Carol ), and Carol has some TrustBucks( Bob ).
 
                Alice and Carol swap TrustBucks( Carol ) for TrustBucks( Bob )
                Alice pays Bob.
 
*       Alice doesn't have enough TrustBucks( Bob ), and Carol has some
        TrustBucks( Bob ), and Carol trusts Alice directly.
 
                Alice and Carol swap TrustBucks( Alice ) for TrustBucks( Carol )
                Alice and Carol swap TrustBucks( Carol ) for TrustBucks( Bob )
                Alice pays Bob.
 
 
Using some combination of the above methods, Alice can pay Bob as long
as there are accessible parties in the system who, in total sum, trust
Alice for the amount of the payment, and there are accessible parties in
the system whom, in total sum, Bob is willing to trust for the amount of
his credit. Which gives the scheme its name: TrustBucks.
 
- -----------------------------------------------------------------------
 
Disadvantages:
 
        Lots of overhead.
 
        Third-party traders must be perpetually available.
 
        Not anonymous.
 
        Not clear how double-spending can be avoided.
 
Not a true disadvantage:
        It could "stall"; that is, there could be catch-22 situations
        where if only some people trusted to begin with, the system
        could continue, but not enough people trust each other to get it
        started. I say this is not a true disadvantage because the same
        thing happens in other currency-schemes, to an equal or larger
        degree. If it's merely more visible with TrustBucks, that should
        not be called a disadvantage. In practice, I think the
        threshhold of trust neccessary to start the system would be
        considerably with TrustBucks than with other systems.
 
Advantages:
        Decentralizable. It is not neccessarily decentraliz_ed_, but can
        become so as needed.
 
        Nobody controls the "mint".
 
        Few conceptual parts. When counting the parts in other schemes,
        don't forget to count the parts neccessary to fix or ameliorate
        problems that don't occur in TrustBucks, like deciding who
        "prints money", keeping them from abusing the role, stopping
        others (IE counterfeiters) from assuming the role, and so forth.
 
I don't claim that the above neccessarily adds up to a positive rating,
but it's worth hashing out, especially if it inspires more secure
protocols along the same decentralized lines.
 
 
- -----------------------------------------------------------------------
 
I'm not the first person to notice that decentralized ideas tend to take
off more abruptly and firmly. For instance, PGP vs. Kerberos, or the
internet vs. AOL, Prodigy, Compuserve. Especially Usenet and the WWW.
That's why I thought a long time about bringing this idea out. Once it's
out, it and its successors are beyond my control or anyone else's.
 
 
 
-----BEGIN PGP SIGNATURE-----
Version: 2.6.1
 
iQCVAwUBMgLz8pi7GCxryNrZAQEfAAQApDzHN9PSpARe/MUZgDDk8F+eFLlKNAHZ
5H6KaX3SlWxL9itM8aFMoudpnBU2gAO7Kn9YHV+dFS1l/tE+NJDhSpTRL1EMKVw9
rGrL8lypX9bLsuw0+thMl1djJjQhc3To6qaLhJvZVji7TRXlKYuVMFW5D6Sm988a
Zg8nRsCQrIo=
=EOKl
-----END PGP SIGNATURE-----