[Webfunds-commits] html/guide Makefile index.html token.html
Ian Grigg
iang@cypherpunks.ai
Tue, 5 Dec 2000 16:50:10 -0400 (AST)
iang 00/12/05 16:50:10
Modified: guide Makefile index.html token.html
Log:
some updates to token description
Revision Changes Path
1.8 +2 -1 html/guide/Makefile
Index: Makefile
===================================================================
RCS file: /home/webfunds/cvsroot/html/guide/Makefile,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- Makefile 2000/07/05 14:28:52 1.7
+++ Makefile 2000/12/05 20:50:09 1.8
@@ -7,6 +7,7 @@
cvs.a \
design.a \
token.a \
+ token_classes.a \
joincvs.a \
wfwin32.a \
access.a \
@@ -16,5 +17,5 @@
ricardian.a \
sox.a \
Intertrader.a \
-
+ custom.a \
1.15 +2 -0 html/guide/index.html
Index: index.html
===================================================================
RCS file: /home/webfunds/cvsroot/html/guide/index.html,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- index.html 2000/10/28 18:14:25 1.14
+++ index.html 2000/12/05 20:50:09 1.15
@@ -20,6 +20,8 @@
</li><p><li>
<a href="design.html">Design Notes</a>.
</li><p><li>
+ <a href="custom.html">Hot-rodding WebFunds</a>.
+ </li><p><li>
<a href="access.html">Access to Source</a>.
</li><p><li>
<a href="mailgroup.html">Mailgroup</a>. Please join.
1.3 +94 -58 html/guide/token.html
Index: token.html
===================================================================
RCS file: /home/webfunds/cvsroot/html/guide/token.html,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- token.html 2000/07/05 14:28:52 1.2
+++ token.html 2000/12/05 20:50:10 1.3
@@ -3,12 +3,11 @@
</head>
<body>
-Status: incomplete.
<h1> Token Money </h1>
<p>
This design note describes how to add Token Money
-- blinded packets in the style of eCash coins -
+- blinded money packets in the style of eCash coins -
to WebFunds.
</p>
@@ -24,7 +23,7 @@
Each is discussed below.
-<h2> WebFunds Wallet </h2>
+<h2> Separate Wallet within WebFunds </h2>
<p>
The most obvious way to add token money
@@ -47,8 +46,8 @@
provides the obvious example.
<p>
-The essential architecture is that of SOX,
-which may or may not be useful.
+The essential architecture of WebFunds is that of SOX
+and Ricardian Contracts, which may or may not be useful.
See comment in
<code>
client/WalletInterface.java</a></code>.
@@ -100,7 +99,7 @@
<p>
A more subtle way to add tokens is to expand SOX. The most
-important reason for this is that it already provides 90% of
+important reason for this is that it already provides 99% of
the infrastructure required to do a token style payment system.
There are other reasons, and disadvantages, which will be
deferred for now.
@@ -110,9 +109,9 @@
Components required include
</p>
<ul><li>
- Withdrawal Request
+ Withdrawal Request (this is implemented currently as
</li><li>
- wallet storage method for coins
+ wallet storage method for coins (not implemented)
</li><li>
ascii-armoured method for coins
</li><li>
@@ -122,36 +121,40 @@
<h3> Withdrawal </h3>
<p>
-The major step required is a withdrawal request. We'll
+The major step required is a withdrawal request. Here, we'll
call such a request a
<code>WithdrawalRequest</code>
(and will require a matching <code>WithdrawalReply</code>
-but we don't consider that further here.
+but we don't consider that further here) but also bear in
+mind that the currenct implementation does
+a variant of the Deposit Request with a flag set and
+a proto payment provided.
+
</p>
<p>
-It will
-sit alongside the
-<code>
-sox/DepositRequest.java</a></code>
+The
+<code>WithdrawalRequest</code>
+sits alongside the
+<code>sox/DepositRequest.java</a></code>
request within the
-<code>
-sox/ValueAccount.java</a></code>
-subaccount (or, possibly, in an
-extended version of same).
-The subaccount would send the request to the
-Issuer (as it is called in SOX terms) that included some consideration,
-and request coins in return.
+<code>sox/ValueAccount.java</a></code>
+subaccount.
+The request is packaged in the SOX Wallet
+with the addition of some consideration
+in order to pay for the returned coins,
+and also a proto-payment presented for signing.
<p>
The above mentioned consideration could be a SOX payment,
some token coins, or some other payment mechanism.
To a large extent, many could be provided in a mature
-implementation, as a configuration option.
+implementation, as a configuration option (only SOX payments
+currently implemented for paying for coins).
<p>
The Issuer, acting as Mint (as it is called in token money terms),
-would settle the value into its minted coins account,
+would settle the value into its minted coins float account,
and would then proceed on the coins withdrawal protocol,
returning results in the reply as appropriate.
@@ -217,7 +220,8 @@
log each phase, then call the subaccount to conduct each
request, and deal with the result, before going on to the
next phase. This would effectively set up a state machine
-within the Wallet.
+within the Wallet. (The implemented DepositRequest variant
+has a state value within it to facilitate this idea.)
<p>
Why go to all this - and more - trouble? Because, in SOX,
@@ -228,48 +232,51 @@
desirable to impose idempotency on the protocol, in that
each request can be repeated as an expected event.
-<h3> Transmitting User Coins </h3>
+<h3> Structure of Token Money within SOX </h3>
<p>
-These sections are not as much work as the above.
+To facilitate the addition of other close forms of
+payment such as Token money to SOX, payments now have
+the following structure:
</p>
-
-<p>
-In order to transmit the coins to another client WebFunds,
-the coins will need to be ascii-armoured. There might be
-two ways to do this.
-
-<ol><li>
- define a new packet that includes the coins,
- </li><li>
- extend the SOX payment to include coins.
-</li></ol>
-
-Then, serialise the packet and ascii-armour it appropriately.
-<h3> Depositing User Coins </h3>
+<img alt="Token Clases UML" SRC="token_classes.jpg" width=500 height=500>
+<p align="center">
+<b>Figure 1. Token Classes (UML)</b>
<p>
-Now, the coins need to be de-armoured, and the coins extracted
-(which is the easy bit).
+In order to add a token money method,
+an extended version of <code>Token.java</code>
+needs to be written. The only one implemented at the time
+of writing is <code>RandomToken.java</code>
+so simply copy that and start hacking.
</p>
<p>
-Once extracted, the coins need to be deposited in either
-a deposit to some account (assume SOX account)
-or rolled over in order to guaruntee that only the current
-client has the coins.
+Additionally, <code>PaymentFactory.java</code>
+specifies various factory methods for converting
+and processing. Read and modify that to suit.
</p>
+<h3> WebFunds Withdrawal </h3>
+
+<p>
+The SOX Wallet now implements its own plugin Payment dialog.
+This dialog is capable of requesting withdrawals in various
+token money types. The types need to be added manually.
+
+<h3> Depositing User Coins </h3>
+
<p>
-The former - deposit to SOX account, is covered by modifying
-the payment to incorporate coins, or modifying the deposit
-request to include coins.
+Once the withdrawal is done, a payment is returned that
+carries the coins in an array of <code>Token</code> objects.
+That payment can now be treated like any other payment,
+and sent or deposited.
</p>
<p>
-The latter - roll-over - is a variation on the withdrawal,
-but this time providing the existing coins as consideration.
+At the moment, that's all you can do as there is not
+coin database.
</p>
<h2> Server-Side </h2>
@@ -278,16 +285,45 @@
components, all of which combined make up a Mint.
<ul><li>
- A double-spending database.
+ A double-spending database. This is currently
+ implemented using existing DBs and indexing off
+ the applicable <code>webfunds.sox.Token.getUniqueId</code>
+ method.
</li><li>
The coin production unit. This is the module that
- creates the signed token, and handles the various
+ signs the accepted proto-token, and handles the various
state aspects of the blinded withdrawal protocol.
- </li><li>
- Double-entry accounts for treasury reserve and issued float.
- </li><li>
- Something to manage access to normal bank accounts, or
- an exchange into an alternate money system.
+ This is all implemented with calls into the
+ <code>Token</code> class.
</li></ul>
+
+<p>
+There are some administrative niceties to do with setting
+up of accounts and permitting token money to be accessed.
+</p>
+
+<h2> Project Status </h2>
+
+<p>
+As of 05 December 2000, status is:
+</p>
+
+<blockquote>
+<dl>
+ <dt><b>WebFunds</b>
+ <dd>Written, evolving to suite other parts.
+ Lacks coin DB.
+ <dt><b>Frontend</b>
+ <dd>Written, untested.
+ <dt><b>Backend</b>
+ <dd>Not touched as yet.
+ <dt><b>Tokens</b>
+ <dd>Only Random
+</dl>
+</blockquote>
+
+<p>
+This project advances on an any-idle-sunday basis.
+</p>
</body></html>