Re: properties of FV

[eric@remailer.net (Eric Hughes)]

   > Net clearing of this form requires the creation of an entire billing
   > system for small value which then settles through FV.  

   No, it doesn't require an entire billing system, because it lives
   entirely on the seller's machine and does nothing except the pre-billing
   accumulation for a single seller.

Just because it's all on one machine doesn't make it not a billing
system.  If it does "nothing except pre-billing", then it doesn't
have the ability to tie into FV.

Such an "accumulation system" has all the properties of a standard
billing system.  It has accounts with accumulate claims, it
periodically asks the customer to pay off liabilities, and it must
check that payment has actually been made.

Just because the values are small, the process is partially automated,
and it all happens much quick does not prevent it from being a billing
system.  Personally, I'd call it a receivables system, because that's
much closer to existing terminology for the actual accounting function.

I'm not trying to imply that you couldn't cobble something up fairly
quickly, but I have my doubts that a good quick hack will scale
appropriately for even a modest sized operation.

   > The very nature
   > of such a net billing system requires linkability of transaction to
   > transaction, or in other words generates identity.  So FV is
   > unsuitable for small value anonymous transactions.

I would still like to you address this issue, if only to acknowledge
the above characterization.

   > At 29 cents plus 4% per settlement transaction, I find this comment
   > disingenuous in the extreme, even after paying Visa for settlement.

   We're charging 29 cents plus 2%, and this includes all the charges to
   the credit card networks, the banks, and our financial transaction
   processors.  We are NOT operating on a big margin here.

As I had recalled from reading your materials, you were charging 29
cents plus 2% on one leg of the transaction plus an additional 2% on
the other.  Rereading, this is not the case.  Am I remembering a
previous situation?

   As I said in an earlier post this morning, this *is* an option we will
   probably support eventually, although I don't think it is as easy to
   make crypto easy-to-use as it is to make checkboxes easy-to-use, at
   least not without deeply compromising the security of the crypto system.

Partial security is better than no security.

Deep compromises only happen if your expectations of the crypto system
are larger than deserved.  If all you expect is a partial solution,
other aspects of the cryptography fall away.  Just because crypto
_can_ do more than one might use it for is no argument for getting
_some_ benefit out of it.

You've not seen this recently on cypherpunks, but I've been stressing
recently the need to deploy partial solutions.  Roughly speaking,
crypto is good for transit security and storage security.  The primary
security problem with FV is transit security, not storage security.
This is a known solved problem.

There are issue of security of private keys stored on Internet
machines.  Were possession of such a key required in order to crack
the system, however, it would be _in addition_ to everything else
already required.  To mitigate key storage risk I would recommend a
key generated entirely and only for use with FV.

One of the underlying conceptual problems with allowing a key to be at
risk is some sort of belief that compromises of secret keys should
never ever EVER be allowed to happen.  This is ludicrous.  When the
benefit of the use of a private key means that it might be
compromised, don't rely upon it's not being compromised.

In particular, if a digital signature does not, by agreement, carry an
implied warrantee of identity, then there's no problem at all.  Use
the crypto entirely for transit security.  If someone hacks your
machine and grabs your passphrase and forges a transaction, at least
the intruder has to grab your passphrase.

Eric