Anonymous writes:
> This gives the mint an advantage over the forger because he will
> generally not be trying to create as many coins as the mint. Even if
> he is willing to spend as much as the mint in order to compete on the
> per-coin cost, he has a time disadvantage because he does not know the
> secret parameters as early as the mint does. This does not raise his
> actual costs but it means that he has to spend his money much faster and
> so needs access to proportionately more computing power than the mint.
> It's an expensive proposition.
This is MicroMint's argument. But you're building a trap door
function out of the advantage the mint gains computing collisions.
It's a shallow trap door function compared to DL or RSA based trap
doors, so the server has to expend nearly as much in CPU resources as
the attacker; and therefore the computational safety margin is much
lower.
It's has higher overhead because of the fast rate of advances in CPUs
and hardware. So the MicroMint supercomputer farm slowly increases
the steepness of the trap door as it gains advantage, but it probably
has to keep up with hardware advances too, so it's not just one
initial large cash outlay for the hardware, there's the continuous
custom hardware upgrades to stay ahead.
It just seems simpler, safer and cheaper certainly in setup, and
probably long term also in avoiding the ongoing costs to keep custom
hardware up to date, to use a real trapdoor function with a much
steeper trapdoor (DL, RSA). With DL and RSA advances in computing
power help the encrypter or signer signifcantly faster than they help
the attacker.
So admittedly DL and RSA are around 4 orders of magnitude slower than
symmetric constructs in software, but the MicroMint initial mint cost
is less than 4 orders ahead, but improving as the threshold effect
kicks in. DL and RSA can use the amortization tricks of hashchains as
used in Rivest and Shamir's PayWord, and Anderson's similar payment
system to help reduce that. Off the shelf hardware also reduces the
difference, and hardware is improving currently faster than ecash is
being deployed.
> Since Millicent [you mean MicroMint] cost per coin falls, the more
> coins you create, at some volume of coins it should be cheaper than
> any other system which has a fixed cost per coin.
The larger initial setup cost has a recurring cost in terms of
interest on the setup cost. We don't yet know whether this is beyond
the level where the threshold to profitability is reached, when you
factor in recurring hardware costs to stay ahead and interest on the
higher setup cost.
Perhaps we can do some back of the envelope comparisons after Bob and
friends publish their cost estimates for the MicroMint custom
supercomputer.
Another assumption which adds to MicroMints risk given the relatively
shallow trapdoor, is the assumption that the attacker has to pay for
his resources. This is a wonderful opportunity for virus writers:
write a succesful virus and earn millions: the payload in the next
I-LOVE-YOU virus could be a rogue MicroMint minting subprocess.
Perhaps the attacker would risk identification as MicroMint by the
sound of it does not provide cryptographic anonymity, but still the
virus attack may be a viable disruption attack against MicroMint.
> > Hashcash also relies on a similar collision function, however the
> > point there is to achieve distributed minting, and so the cost is
> > distributed, and seen as a side effect incurred to achieve the
> > decentralisation of control. Millicent does not make use of
> > opportunities for distributing overhead, and so incurs the overhead
> > without gaining the decentralised architecture.
>
> It's never been clear how or whether hashcash could work as a true
> micropayment system. What would establish the value of a given hash
> collision? Who would be willing to receive hashcash and pay out real
> money?
Well I didn't intend it as a true micropayment system. But see Wei
Dai's b-money [1] for an approach to having transferability and value
to an ecash system with a decentralised minting function.
> With a mint based system like Millicent the mint will work with an
> money changer who will make sure the coins have value by buying and
> selling them for dollars (or whatever). That's a necessary step in
> getting the payment system accepted.
It may be feasible to get hashcash accepted as a distributed resource
metering system, simply to resist systematic abuse of otherwise
unmetered services, and so make services available which could not
otherwise be offered due to vulnerability to abuse.
Sure real ecash is better, but hashcash is here now and ecash isn't
yet. At least not in any widely deployed form, for many reasons:
- the chicken and egg problem;
- the communications overheads for a centralised payment system
capable of supporting wide scale micropayments are themselves a
significant engineering task
- interacing to the existing payment system for in and out payments;
especially in payments and the high fraud rate, lack of security, and
false repudiation problems plaguing credit cards.
Adam
[1] http://www.eskimo.com/~weidai/bmoney.txt
