> Subject: > Separation of Control -- A Principle of Financial Cryptography > Date: > Sun, 8 Jul 2001 13:37:47 -0400 (AST) > From: > Ian Grigg <[EMAIL PROTECTED]> > Reply-To: > [EMAIL PROTECTED] > To: > [EMAIL PROTECTED] > CC: > [EMAIL PROTECTED] > > > Separation of Control -- A Principle of Financial Cryptography > > > As a Financial Cryptographer, I've been thinking a lot > lately about the Governance aspects of systems that deal > with electronic value. > > Financial Cryptographers do this. Especially during our > occasional conferences where new systems present challenges, > sometimes new and sometimes familiar [1]. > > Imagine a system storing some physical commodity like > greenbacks or bricks or somesuch. Then issuing the > commodity in digital form. With Ricardian Contracts, > or some other technology. Our recent EFCE conference > in Edinburgh presented a bunch of these to a skeptical > and critical audience [2]. > > I've written extensively on how to protect the assets of > such from internal fraud and so forth [3]. I use a fairly > simple management accounting or agency concept that I call > my 5 parties model. It's all written up extensively on my > site and occasionally appears in published papers [4] and > some internal papers [5]. I consult in this area, as do > others. > > One of the things that we do is to advise the issuers of > value -- by whatever means they issue -- to separate out > their risky components from their non-risk components. For > example, the Issuer of value should be separate from any > entity that buys and sells value for a spread, and takes a > risk on same. > > This point takes some time to appreciate, although it is > well-bedded in accounting and finance principles. An > entity that buys and sells takes on a risk in the position, > as well as dealing directly with lots of parties who also > take on risk. > > In contrast the core payment system takes on no risk if it > is 100% reserved with strong back-to-back contracts. It > only deals with users of payments in a highly contained > context. > > The exchange operator -- let's call her Matilda -- should > indeed take on risk, as in this way she earns profits, > normally by setting a spread. The payment system -- we > call him Ivan -- should not take on the risk, as he holds > the value in trust, or escrow, or similar, on behalf of > users. > > The payment system is thus a juicy target. Fat, smiling, > and somewhat detached from the users, a bit like those > western images of a buddha. Meanwhile, the exchange > operator is elusive, quick, nimble, aggressive, and as > skinny as a wraith, like the ladies in Crouching Tiger, > Hidden Dragon. > > It's an analogy, no more, there are some quite nice exchange > makers out there, and they are not that skinny and no doubt > some unsmiling payment systems as well. > > Unfortunately for all, our wraith-like Matilda generates > the greater degree of suits, as she is in fact taking on > the riskier business. It sort of goes with the territory, > all those martial arts movies show her getting into bust-up > after bust-up. But, she has few assets on hand. So she > takes her profits, just today's profits, and moves on when > her luck runs out. > > What happier situation for the attacker to find an exchange > operator sitting hand-in-hand with one of those juicy 100% > reserved payment systems. > > >From the point of view of the non-aggressive user (let's call > him Bob), he should bear in mind that what is happy for the > aggressively-minded Alice is unhappy for him. A payment > system with a nice pot of reserves and one of those risky > exchange operation all mixed into one is likely to attract > the worst sorts of attention, and thus endanger those > reserves. Don't know when, don't know how. Trouble has > a habit of creeping up on these situations. > > I therefore often advise concerned parties to separate out > the payment system from the exchange operator [6]. Further, > we anticipate that wise users will look for: > > * different owners. let the exchange operation go free, > let it profit, so that the Ivan the payment system can > live happily, smiling, safe forever. > > * make the payment system as risk-free, and as low profit > as possible. > > * look for separation of control. Be religious about > this point, a secret marriage is not a good one. > > * look for true competitive access to the core float > feature (adding more value to the total system). There > are logical reasons for restricting access to the core > float feature, such as competitive control and admin > costs. Only one of those works to Bob's benefit. > > * look for strong legal and jurisdictional institutional > aspects. I.e., the contracts are strong, the courts > are behind it, the lawyers are honest, fair and quick, > the integrity is evident. > > * look for fair treatment of users by the all-powerful > payment system. Nothing raises a judge's eyebrows > faster than a small guy with a valid complaint against > some big silent guy. > > * look for quick dispatch of threats. A permanently > fixed smile will still be there whilst being torn > apart by a threat that wasn't perceived as such. > > Sometimes my advice is accepted. Sometimes not. Often times > it doesn't matter, when all is going well. When it matters > of course is when the storm clouds gather, when the legal > vultures circle, when the regulators start to agree that > they are disagreeing with the state of affairs, when some > unfortunate soul makes a mistake and topples the buddha over > on his smiling face. > > Like a stock market bubble, or a ponzi scheme player, the > smart user hopes and prays that he can see the crash. And, > in like fashion, most of the users will not, and will be > crushed by the fall. (There's a smart rule of thumb from > the investing world in this case: never invest more than > you can afford to lose.) > > For this reason there were many incisive discussions when > new payment system operators recently faced the ritual > grilling in EFCE, held in the fabulous and legally imposing > Signet Library [7]. Like initiation in some mildly secret > but harmless cult, the key players in the Financial > Cryptography industry turn up to see the newest and > brightest of the next generation. > > Many of tomorrow's Ivans and Matildas were there to display > their systems to the brightest and nastiest in the industry. > Some left with a quizical smile, others with a frown, and an > occasional grinning confusion. > > I don't want to embarress those that turned up and made their > best efforts, it's always difficult for a payment system to > have their smile wiped, however briefly. But, we are in a > world where users are getting wiser about how they like their > payment systems to comport. It will be interesting to see > this year's new entrants respond [8]. > > Come next year and find out for yourself! > > iang > > > -- > [1] Including, payment of conference fees. As organisers of > Financial Cryptography conferences, we try to accept payment > of fees in the new monies so-presented. > [2] http://www.efce.net/ > [3] http://www.systemics.com/docs/ricardo/issuer/FAQ.html#governance > [4] http://www.iang.org/papers/fc7.html > [5] No URL available! > [6] In Management Accounting, this is sometimes referred to > as "separation of control." > [7] http://www.efce.net/signet.html > [8] We've recently opened accounts with some of them and are > taking payments for various services that we offer. > -- http://www.constructiongigs.com/ Use gold as money. It's easy. Create a free e-gold account here: http://www.e-gold.com/e-gold.asp?cid=101670 ConstructionGigs.com's PGP public key is here: http://www.constructiongigs.com/assets/DH-DSSkey.txt Fingerprint: 3C4D A63F 3C8B 2D7B 7E1A FFE8 9A2E 4D78 CAD6 66B7 --- You are currently subscribed to e-gold-list as: archive@jab.org To unsubscribe send a blank email to [EMAIL PROTECTED]
