Re: [decentralization] Guide to DMT Rand operation
- on 12/31/01 12:11 AM, Todd Boyle at tboyle@... wrote:
>>> DBCs and DMT are stuck today for the same reasons all of the products[snip]
>>> from trad banking and software vendors are stuck: there is no secure OS,
>>> or even secure *device* that is fit to contain cash.
>> Even the iButton or smart cards? Besides, it's just another kind of risk;
>> why is the risk of having some digital cash lost or stolen that much worse
>> than the risk of having a credit card payment refused?
>I wasn't suggesting it too seriously; I just wanted to throw out an example
> I can't believe you are suggesting the iButton or smart cards as
> a solution for this problem...
for you to tear apart. After reading your analysis I remember why a secure
UI is also needed to manage digital cash
> I guess you are thinking, we will onlyNo, I think that would be worse because you never know what the terminal is
> use the iButton or SmartCard at retail terminals?
saying to your device. (like "This is a hold-up! Gimme all your digital
Wes Felter - wesley@... - http://felter.org/wesley/
> It's a bankable asset. Just like cash. All you have to do isAgreed, but I'd change the 'when' to an 'if'. Cash cards generate
> convince your banker. If your banker is the issuer, then that's easy.
> The others will come along when the business volume is high enough.
higher value if they are paid in advance, and if they have a high
degree of non-use (like rebates). The more they behave like actual
cash, the less they have those properties.
So I'm not disputing that they can be made to behave like cash, I'm
disputing the business case that would lead to that outcome.
> The infrastructure requirement can be reduced from hardware andBut the differences you gloss over here is that the "bank" is actually
> maintenance overhead (which scales with volume) to complexity overhead
> (which amortizes over volume), by decentralization. The benefits
> remain, for the "bank", which gets your USD/EUR/CNY *now*, and pays
> out later.
several banks, and you can't easily decentralize if you're Starbucks
or McDondalds. So when McDonald's banks my money but I buy coffee at
Starbucks, to Starbucks that's _worse_ than a cash transaction, and
when Starbucks takes my money but I buy at McDonald's, Starbucks takes
on the overhead of dealing with an external creditor and the risk that
the average purchase at McD is larger than the average purchase at
Starbucks, thus depleting their advantage faster.
So, Starbucks would make more money than the present situation if they
sell so many more more of the new interoperable cards (or sell at high
enough values) to offset a) the additional expense of honoring
external cards (== 30 day billing as opposed to ~5 with banks), b) the
(small) overhead of an additional creditor and c) the risk that the
money will disappear faster if its more useful.
(As a side note, Starbucks specifically envisions non-use as a common
scenario, and has contractual provisions for draining your account
after a year. See http://www.starbucks.com/card, Terms and Conditions)
Furthermore, the new 'card as cash' has to be more attractive to them
than simply saying "If we want to accept external cards, the existing
infrastructure is fine with us."
So my contention is that on the profitibility scale
Store card > Existing Infrastructure > Fungible cash card