SnowDog wrote:
> > > A great idea Vincent, but it would be difficult to get this happening
> > > *AS YET* as the volume of e-gold transactions are (relatively)
> > > miniscule.
> >
> > E-Gold has a huge transaction volume in comparison with thinly traded
> > stocks, and even thinly traded stocks benefit from an exchange where bids
> > and asks are posted in one place.
> The DigiGold Trader Program allows DigiGold account holders to exchange
> DigiGold with each other between DigiGold (Silver), DigiGold (Gold),
> DigiGold (Platinum), and DigiGold (Palladium). The volume on the DigiGold
> Trader program is as thin as can be, but the spreads between the metals are
> fairly narrow.
> Craig

e-gold would need to be put in contract form. Plus there would need
to be an underwriter.

This would still be a money changer like JP says. I believe it
would have to have excellent account service, for real, along the 
lines of Charles Schwab and some of the current e-gold money


> Subject: 
>            Re: implementations of "XML Voucher: Generic Voucher Language" ?
>       Date: 
>            Mon, 05 Mar 2001 12:59:35 -0400
>       From: 
>            Ian Grigg <[EMAIL PROTECTED]>
>         To: 
>            Ko Fujimura <[EMAIL PROTECTED]>

>        CC: 
>            Rachel Willmer <[EMAIL PROTECTED]>, [EMAIL PROTECTED], 
> References: 
>            1 , 2
> Ko Fujimura wrote:
> > 
> > Hi Rachel,
> > 
> > > Are you familiar with Systemics Ricardo system, which uses Ricardian
> > > contracts to implement the concept that you call "vouchers"?
> > >
> > > <>
> > >
> > > This system has been around for about 5 years and has been used in the
> > > fields of currency, stocks and bonds. The use of "Ricardian contracts" or
> > > "vouchers" is a critical part of the architecture.
> > 
> > Yes, I read his paper presented at FC'00 about one year ago. I like the design of
> > the Ricardo system since it provides both flexibility and simplicity using modular
> > software components.
> Thanks!  The paper is at and the
> software mentioned is at .
> > > We're in the process of integrating their Ricardo system into our
> > > CashBox(tm) system, and I'm interested in knowing about any other companies
> > > who may be implementing other payment systems based on these concepts, so
> > > please do let me know when others do implement.
> > 
> > Our FlexTicket system is a smartcard-based value/rights circulation system and
> > provides transferability and offline capability. There are more information on
> > the protocols presented at CARDIS 2000.
> > <>
> I had a look through this yesterday and put some information
> on the proposal, as an 'alternate' to our Ricardian contract
> concept, up on the webfunds site:
> What is very interesting to us is that we may be able to use
> your formats for the Ricardian Contract in XML -- it is a future
> task for us to convert to the XML world for all the normal
> reasons.
> (The comparison come across as a little unfavourable because
> it tries to measure the Voucher against our own internal
> contracting requirements, which are accepted as being quite
> fierce!).
> > Through the development of early version of this system, we learned importance
> > of standardization of "contract" or "value description language" that describes
> > what/how values/rights are traded between the trading partners.
> Do you mean the term "contract" in its legal sense, or in the
> information sense?  That is, the law of contract applies, or,
> that the "contract" or interface is specified as per programming
> needs?
> If you mean the term in the sense of law and negotiating parties,
> I would wonder how the Voucher could stand up to a dispute?  In
> the Ricardian concept, we insist that the contract be readable
> by humans, linked to the asset in question, signed by the Issuer,
> and some form of open PKI in operation that provides evidence of
> intention, and other devices to maintain the consistency of the
> contract under a wide degree of circumstances.
> (Although, we are mostly concerned with English common law contracts,
> I haven't got a view as to how they stand up in other legal domains.)
> > We are going to implement XML voucher as soon as it completed.
> You may find the framework in WebFunds to be of interest.  There,
> we have a contract browser that reads in the contracts, verifies
> the signatures, and can display the text.  There is also a nice
> contract signing wizard that takes you through the process of
> doing your own contract.  It's early days yet, this is really an
> automation tool rather than a replacement for the complicated
> process of underwriting;  it doesn't give you enough help in order
> to write your own contract, if just automates some of the tasks
> that are bothersome.
> > By the way, I think that generic value transfer protocols like the Ricardo' SOX
> > protocols are exciting and important. But, I think it is difficult to cover all
> > application area using one universal value transfer protocol. We therefore think
> > that "contract" should contain a parameter that specify which the protocols
> > (or "VTS provider" in XML Voucher) are used. I think it will help to develop
> > generic digital wallet like your CashBox(tm).
> That's an interesting point.  In our system, the identity of the
> contract is provided by a canonical message digest (calculated
> over the readable contract) which is used as the identifier in
> payments.  There is nothing in the SOX protocol that limits the
> usage to that digest, and nothing in the Ricardian Contract that
> says which protocol to use (and indeed, it is possible to plugin
> a separate payment system into WebFunds, and use Ricardian Contracts),
> it's mostly an implementation issue.
> However, there is ample flexibility in the contract format, and 
> indeed, any similar format like your XML Voucher one, to add a
> limitation of protocol.  That might become interesting in the
> future as we are adding different transaction types to WebFunds
> as a background task, and are using Ricardian Contracts in areas
> that don't involve SOX directly.
> -- 
> iang

You are currently subscribed to e-gold-list as:
To unsubscribe send a blank email to [EMAIL PROTECTED]

Reply via email to