[Lucrative-L] lucrative accounts revisited

R. A. Hettinga rah at shipwright.com
Tue Apr 22 23:13:54 EDT 2003


--- begin forwarded text


From: "Patrick" <patrick at lfcgate.com>
To: <lucrative-l at lucrative.thirdhost.com>
Subject: [Lucrative-L] lucrative accounts revisited
Date: Tue, 22 Apr 2003 17:59:52 -0600
Importance: Normal
Sender: owner-lucrative-l at lucrative.thirdhost.com


	First, I would like to thank two people for donations sent
today, totaling approximately $600. One wishes to remain anonymous for
the moment, and I have not secured permission to acknowledge the other.
But I am very grateful for the show of support this represents, and my
wife is very grateful that the phone is now reconnected.  :)

	After some thought, I have decided that some of the spectre of
"accounts" can be removed from the Lucrative client, mint, and protocol.
As discussed in a previous message to this list, I do not think that
Lucrative accounts are similar to bank accounts or anything like that,
but this part of Lucrative has caused some controversy and I want to
correct it.

	My proposed revisions are five:

	First, the interface packages will no longer deposit funds in a
holding account for users to "pick up" as DBIs with their software
clients. Instead, issuers/exchangers will simply present the user with
an ASCII-armored FIBI, the full DBI, no account mentioned.

	These DBIs will not be fully blinded, as it's the issuer or
interface package that's requesting fresh coins from the mint and not
the end user. When importing the DBI into her client software, the user
should, as always, renew the DBI with the mint.

	Second, the deposit and depositFIBI APIs will be removed.

	Third, the term "Account" will be replaced with the term
"Envelope" where it is still used. createAccount() will become
createEnvelope(), for instance. getBalance() will be repurposed or
rewritten to be specifically and only used for failure recovery (as in
Fourth, below).

	Fourth, the reissue and reissueFIBI APIs will be altered so that
they can optionally take a disposable Envelope number. A client that
wishes to protect itself from server or network failure can use an
Envelope number to recover from failures during reissueing; it won't be
otherwise used.

	Fifth, all mention of "accounts" will be removed from the Purse
GUI as they are no longer necessary. The Purse will be updated to take
advantage of the Envelope failure-recovery procedure, but this will be a
largely internal function.

	The result of these changes should be to eliminate the word
Account and to remove the idea from client software and end users'
conceptual framework. Alice and Bob will never see an Account or have to
know that their wallets may very briefly use an Envelope, which bears
only vague resemblance to an account, and then only during failure
recovery, which should be quite rare.

	Comments are especially welcome on this proposal. Once this is
out of the way, I will put forth my plan to support transaction fees in
Lucrative mints.

	One last thing, there has been a little confusion about this. I
am not Patrick Chkeroff, and he is not me. My name is Patrick McCuller.

	Thanks,


Patrick


The Lucrative Project: http://lucrative.thirdhost.com
......................................................
To subscribe or unsubscribe from this discussion list,
write to lucrative-l-request at lucrative.thirdhost.com
with just the word "unsubscribe" in the message body
(or, of course, "subscribe")

--- end forwarded text


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list