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 changers. Bob > 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], >[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"? > > > > > > <http://www.systemics.com> > > > > > > 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 http://www.iang.org/papers/ and the > software mentioned is at http://www.webfunds.org/ . > > > > > 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. > > <http://info.isl.ntt.co.jp/flexticket/papers/> > > 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: > > http://www.webfunds.org/guide/ricardian.html > > 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: archive@jab.org To unsubscribe send a blank email to [EMAIL PROTECTED]
