needs in OpenPGP to use it for a bitcoin replacement.

[Jbar]

> > But bitcoin has also technicals defects, the two most important are :
> >  - a amount of bitcoin is only stored by only one peer at a time t, which
> > 
> > mean that bitcoins  may easily disapper and that is what already occurs
> > (I did personally lost a few amount of btc, and i had see in the forum
> > that I am not alone).
> 
> Not sure I see this point. If you loose access to your private key, you
> always loose your digital money. That's a fact of life, and the reason we
> do backups.

I have make backups of the private part of my OpenPGP certificate once. With bitcoin u should make backups after each transaction...

> >  - Transaction are very very slow (I don't have try to pay taxes to the
> > 
> > people "with the biggest" CPU power), and this is not a surprise why so :
> > first
> > the proof of work, second  there is in fact a third-party  for bitcoins :
> > it is the entire network.
> 
> The proof of work is an essential economic measure in the bitcoin network.
> How would your proposed system work without a proof of work? Why would
> anyone join in?

We will use OpenPGP web of trust and it will be human-based instead of CPU-based.
People who think than society in based on humans more than on institutions or CPU should join in. 

> On the third-party, there needs to be a third-party for a digital currency
> to operate. Otherwise I can use one coin multiple times. If that
> third-party is the whole network (i.e. "the public"), then that's as good
> as it gets -- no single point of failure or entity w/ too much power.

Of course we need no single point of failure or entity with too much power, but there is a more efficient alternative than a big single network :
A network of networks (of networks of networks...) which mean a tree of network, to be compared with the DNS system tree (and as fast as n^n grow , we 
don't need a deep tree).

> I think the whole bitcoin story is questionable enough. I'm not saying
> bitcoin can't be successful, but you should be wary and make a careful
> decision. Everyone has different opinions about it. Adding "yet another
> system" on top of that won't help.
 
I just want that gnupg manage a new  subpacket type octet (cf the section 5.2.3.1. of the RFC 4880) needed for the signing chain feature :

"The value of the subpacket type octet may be:
 (...)
               33 = Recipient
(...)
 5.2.3.27.  Recipient

   (8-octet Key ID)

   The OpenPGP Key ID of the recipient of the signature.

   This subpacket may be used for signing chain, and so in the hashed
   subpacket data set. This subpacket may be used many times if there
   are different recipients.
"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 316 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20110526/37e0e51a/attachment-0001.pgp>