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