[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [freehaven-dev] Attack on timing of trades
On Fri, Feb 04, 2000 at 03:46:47PM -0500, Brian T Sniffen wrote:
> There are two nodes, A and B, which trust each other. A is good, B is
> evil. They're about to do a trade:
> A: "I've got a 1 meg for 1 month share."
> B: "Me too. Let's swap. Here's my share."
> A: "OK, here's a receipt saying I've got your share. And here's
> my share."
> B: "You've got responsibility for my share. And I haven't given you
> a reciept for yours yet... so you keep both. Bye!"
> It occurs to me that shares should travel back and forth first, and
> that receipts should travel in some form of blinding so that they can
> only be simultaneously revealed. (Is that possible?)
> Alternately, we expect the above situation, drop B's share on the floor,
> broadcast that he's being evil, and take the trust hit for it.
Well, we have to keep in mind that we can't afford to send very
many messages in the exchange -- the latency of the mixnet mandates
So we really can't do any of the incremental-exchange algorithms
as I know them (I might be wrong and it might be that we could get
'enough' of them to be worthwhile in only two iterations...)
So the options as I see them are:
1) "Hey David, find us a good mixnet that has very little latency."
2) Bite the bullet and take the trust hit. I want to avoid this because
I want to avoid situations wherein it's just one server's word against
another and it's easy to spoof situations just to screw somebody over.
(Or am I off in my own little dream world, and these sorts of situations
are going to be very common and there's nothing I can do about it?)
3) Somehow send receipts or status messages or something to somebody else
who pretends to care long enough for the transaction to complete.
Presumably he'd back up the fellow who had the legimitate gripe if
something went wrong, but I can't see how one server is going to lend
much credibility to anybody...(and I can't see how it's reasonable to
involve many servers.)
Besides, the receipts are mostly for the buddy. Unless we were planning
on using signed receipts to lend weight to broadcasted claims?
4) Come up with a solution to the above exchange protocol that makes
everything work beautifully. I don't see one, and I can argue
convincingly that without either involving more people or using more
iterations, it can't be done...
5) Did I miss one?
Excellent question. This is that whole commitment-without-a-trusted-party
My first reaction is to ignore the complex protocols and just hope that the
trust system is robust enough to handle it (simplify, simplify!)...but we
really shouldn't hope that about too many different problems. :)
I'll keep thinking about it...