needs in OpenPGP to use it for a bitcoin replacement.

Jerome Baum jerome at
Thu May 26 18:46:25 CEST 2011

On Thu, May 26, 2011 at 17:41, Jean-Jacques Brucker <
jeanjacquesbrucker at> wrote:

> >

> "How would your proposed system work without a proof of work?"
> >
> > You haven't explained how the currency works. Where do the initial
> "coins"
> > come from? How are they generated?
> That the main point were we need a bitcoin alternative. Bitcoin don't care
> about humans, and lacks fairness.
> Imagine a world with gold mines (I know bitcoin fan like gold)

Not really a bitcoin fan here, and I think gold is a pretty bad analogy that
breaks down very soon. How about coins instead? The idea here is that coins
can be generated without limits (i.e. don't need to be mined -- assuming no
lack of resources that the coins are made of).

> Each humans validated by a given OpenPGP web of trust may generate
> periodically its part of a new monetary mass which is created by the rule
> defined by the Relative Theory of Money (may be adjusted by the vote of the
> human in the given OpenPGP web of trust)
> cf 5th rule of (I don't necessary
> agree with other rules in this page, but a community have to accept common
> rules, they may be as minimal and democratic as possible, but still remain).
> The list of humans (OpenPGP KeyID) why satisfy a  given web of trust (which
> web of trust ? of course there is here a problem of entity with too much
> power to resolve) is publish before a set of money is created. And so is the
> amount of money that each human may create in this set.

This is particularly difficult to resolve. A digital currency should allow
any two people to trade without having met each other before. Bitcoin allows
this, while a WoT-based model requires at the very least a chain between
those people and cooperation along the chain.

> example : for the set number nt, there is nh humans in the list, each human
> can create 2 bills of value 50 and 4 bills of value 10.
>  The first person in the list may use new bills of value 50 numbered 0 to 1
> in this set, and new bills of value 10 numbered 0 to 3 in this set, etc ...

So, the system doesn't allow new people to come into play after it has been

>  If a human in the list don't create its part of money, he is supposed to
> be dead and is (until he comes back to life) removed from the given web of
> trust.

Don't get this part.

> > If we have a network of networks, I can use the same coin twice -- once
> in
> > network A, once in network B. Or, I cannot use the coin from one network
> in
> > another. Or, I need a third-party.
> Not if networks are prioritized in a tree structure :
>    /B1
>   /
> A  --B2
>   \
>    \B3
>  Every B networks watch its root network A, use it to make transaction
> between them. But network B2 and network A don't care about the money
> exchanged in network B3.

So say I am in network B3 and you are in B1, how do I send you money?

> > A more in-depth description of your proposed system would help, before
> > making requests to change OpenPGP. (As David points out, this isn't even
> > necessary -- nonetheless, you'll probably save yourself lots of time if
> you
> > just write up a document about this and have others review it, as opposed
> to
> > "just going ahead".)
> Indeed David solution is sufficient for the needs. I did think of using the
> Notation data too, but I did forgot since, (Thanks David to remind me it :-)
> ) the reason is that it seems dirty to me :
> I hope I am not alone which want to use OpenPGP for signing chain.

For a first implementation you'll have to go with notations if you want to
use OpenPGP. Otherwise you get compatibility issues etc.

> > This isn't what I meant with "yet another system". "Yet another system
> [like
> > bitcoin]" is "yet another digital currency system", i.e. "yet another
> choice
> > the user has to make", analogous to "yet another operation system" or
> "yet
> > another Linux distribution". Not that the ability to choose isn't a good
> > thing. But the shear amount of distributions has been a problem for
> Linux's
> > market adoption in the past. This has improved as a number of distros
> have
> > emerged as "significant", but the point remains valid -- don't add a
> system
> > if you're only making one small change. Document how your system will
> work,
> > which security features it addresses and how, and share this document
> with
> > others to get some review. Especially share it with the bitcoin authors!
> >
> As a bitcoin is now exchanged for 8 $ (,
> and the bitcoin authors are the best served in bitcoin (
>, I am not
> sure they would like to work for a human-based alternative before selling
> their bitcoins at a highest price.

Not sure I get your point here. Are you implying the bitcoin authors are
scamming people?

How about you draw up a list of requirements that your system is meant to
solve? Right now I see a complicated model but you haven't established the
ground rules yet. E.g.:

§ 1. Any entity may enter and leave the network at any time, and not loose
or gain money by doing so.

§ 2. Any two entities may exchange money with little to no cooperation from
the network; and there is an appropriate incentive to cooperate as far as
cooperation is needed.

§ 3. The time required to exchange money must be small; and the fees
required to exchange money must be minimal.

§ 4. No entity may gain wealth without cooperation from those who in turn
loose wealth.

§ 5. Transactions should be anonymous with the exception of traffic

(Input welcome!)

This is just an example and you'd adjust it to suit your needs, but I think
it's a good start. You mentioned that you're not interested in § 5, so you'd
obviously leave that out.

Once you've defined a specific goal, it will be much easier to verify that
you're reaching this goal. Otherwise everyone else has to make assumptions
about what you're trying to achieve. It also hinders promotion: If I can't
see what features your currency has to offer, I'm not going to pick it over

Jerome Baum

tel +49-1578-8434336
email jerome at
PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A
PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20110526/e22d329f/attachment-0001.htm>

More information about the Gnupg-devel mailing list