Sample Cash

-----BEGIN SIGNED CASH-----
Hash: SAMY

<?xml version="1.0"?>

<token
 version="1.0"
 state="spendableToken"
 denomination="25"
 assetTypeID="d7a11ee80460a10b91a4ad49069a7fc2a34c349433ffbd33dad7e31ba8b170d482c524a911c1569ccde5a11e68"
 serverID="0bb39523d6b54381c5477aeae808cb51dfbada7bd256e3a0298273a59772f5ad93cd5dee4e6061283dcffd1447"
 series="0"
 validFrom="1281865563"
 validTo="1297417563" >

<tokenID>
AAAAgGZdHsse3IXV4VTvm78X5uFwrmSuc116m3dSS2ueXbAKQnSeADKyUoBa8Dem
isNgXcjfbfVKsrVAPR3kNd9xCFY4uR7nMBSOHKrCaUSpUVVgB8IOYtgOmPQTXiuE
wtJrxofv947QBuP8RnVvf0ZVt0xLL6zlbpk3UW4iDIr0HXmuQQ49q/vJdWJjSHRF
Q/nt0BN5mxFiSbXyKr7no+QC0u7Sr78jYI3Itn67J3uaMmxBmA4JrIrHse36ABuW
zxecCkTNki9Om5bl6c1QgM/N1gogWX3n4o7Zz+7Dw7zt1e/7nG6AYlOT3kfpXNnT
8xojuyaiSINDQOoJboc0tq2CnX+ma6CNC7bQKtN69SZJs14DseqKquWe7gwCHPTo
ewSsKeRmTjzxDhjnFNLRRJGhC4bvH/tZD0UE8EY0X83mvQiNJ/5on2SxTxanJXNt
iCj3+Uczaa0CQ1fQ6ubrwbpeWgZRzB3CUtHTsLVhPSBkEnRbndyFEehfb6rKyEqs
kfEaa1LdiBj/MctrP6EBbGcrmixnr820KLXmFNjDhhybeFNK/cTRuYw7cWra4/S9
F4QViwCmlLToMwOCYmwMpm//HFn4eQSLsMcP+gVAXme9YmVTlEKupQGV+EbJ/gnO
prlZxQ==
</tokenID>

</token>
-----BEGIN CASH SIGNATURE-----
GAry6ydopTPrPMs1V+9EPvszmZQsRkOtqm+5QeUywyEyOUoFuJJfHhPxMWPbupf/
cq+vBf0JwK5yy/XA2Pzom80TPTry4JpxXckx/JcmyUikhocTY01sDZNcXzEfBvQJ
kIeADfmw/4/adTjHhVCy4k+OdGFvdIwfNIdbVfsfKfg=
-----END CASH SIGNATURE-----

People have asked why the denomination “25” is human-readable in the note. They assume it is only supplemental and the actual amount is somehow stored in the Lucre blinded data.

BUT IN FACT, the Lucre blinded data contains only a Token ID. The denomination (“25” in this case) is necessary so the server knows which minting key to use when verifying the note (it definitely won’t verify if the wrong key is used.) Similarly, the wallet needs to know the denomination for unblinding the note, during the withdrawal process. So that number is there as part of the protocol, and the note will not verify if the wrong denomination is substituted.

Decrypting the tokenID (from Lucre and stored on the Note):

id=A4C05DF4C43B77EBF02309502E5FB3F30C5811886254DD8B9B0C2791
signature=9F29D79A07D48D467874DE7F76B5EF02646835A47DD576221612DA1A9C4A531C
10DFF2BECB5EC72D13F2C1DE3EB885636085F09CF33F80125BB2EA3CEA01EA6B112125E29E
796FD889CBA467B1F5B9BF4FA2FFEA8AB4C111D84F4E7236B70A42CE3137FB23DEBE79FF37
B6C161A3F77009EF714E8D0CE528B5572DA58155D59C

---

All cash tokens have the exact same expiration dates as the mints that created them. Tokens are sent back and forth between the client and server by bundling them into a purse and adding them to a withdrawal or deposit transaction.

For example, a certain currency may be in its third series, (SERIES 3), with all tokens valid from January 1st through June 31st, and the mint itself expiring on March 1st.

On March 1st, SERIES 4 would come into operation, with all tokens valid from March 1st through September 30th. (At this point, the Series 3 tokens are still valid as well — the server would accept both.)

In June or July, SERIES 5 would come into operation, valid until December 31st, etc. Around this same time, the Series 3 tokens would finally expire.

Because all tokens for a specific series have the exact same expiration date, the date cannot be used to track the cash — thus, it remains UNTRACEABLE. Your wallet software can also compare the tokens to the Mint public file (for the correct series) and verify that they all have the exact same expiration date.

Once a specific series has expired, the spent token database for that series can be DISCARDED and does not have to be stored any longer by the server operator.

This is fully-functional now, and makes it much more practical to operate a server.
Wallet software can automatically do the job of exchanging tokens if they are close to their expiration dates.

Opportunity for wallet designers: If your wallet is unregistered, you exchange all expiring tokens and keep them for yourself. But if user pays registration fee, then you automatically exchange them for the user. Nifty?

NOTE: the tokenSignature Lucre data no longer appears in the spendable cash notes. It’s used to unblind the token after the Mint signs and returns it (during the withdrawal process) and then the signature is discarded because it’s no longer needed and because it could be used to trace the token. You may notice the Open Transactions cash notes are a little smaller now, because of this fix.

I kept the below signature decode for historical reasons, since this field still occurs in signed tokens, though it is removed by the time they are unblinded and become fully spendable.

Decoding the tokenSignature, from Lucre and stored on the signed, (and still blinded), note:

request=2331FBA771EB4DF7DFCD3D4DFD9F3DA5F43A90C7A00EC599C557E8C82D9679BB0F
2AEF36ECBCA3C551B5C7E134C151AC93779415E695C5CDDD753DE245DF31904EEFC1D3E3D4
64E5DB27E80AE65355004DC869CF47BBDCD2B79EF2F23A0412826EE9794E9B8BA07E03C417
A59EC2CB74195FB2714E1CBAE49EF89D5A672CA6BA
signature=8B29439A2CA05CE28C416A8C5395123468A8E8505C1B2FC1568910B27759B652
971240C975D1422C9ADC35368A6A6B439F1D4614C52713A82C9B662E9099121324DD4BEA5B
76AD123F9912AB43A47AC590FC1DCED905C10B72B418107FD709D57D8DEC779896F48989C7
2171D01BCB15673CCF36B2FFCC29B9D986FCFE97E689

To read about the OTMint object, click here.
To read about the OTPurse object, click here.