why deposits removed?

[dsernst]

trying to understand the motivation why @weijiekoh removed deposit functionality here: ad6bdb6 as part of #60

Seemed like a powerful mechanism from vitalik's original proposal. Was a flaw found?

[dsernst]

Each user is also expected to put down a deposit; if anyone publishes a signature of their own address with the private key, they can steal the deposit and cause the account to be removed from the list (this feature is there to heavily discourage giving any third party access to the key).

— Vitalik's post

As originally proposed above, I believe there are at least two significant flaws:

Claim 1: Is successfully collecting the deposit also a race condition?

This was asked by @barryWhiteHat:

How does the withdraw of hte deposit works?

If I start with key x and update it to key y do I withdraw with key y ? Is the withdraw public in the smart contract ? Is the withdraw protected with the same coersion resistance mechanisim ?

I propose this could be defeated by bribing with a smart contract that says "if & only if the MACI contract withdrew [deposit amount] to [briber's address], [bribee's address] can withdraw escrowed [bribe amount] from this bribe contract. Otherwise return [bribe amount] to [briber's address]".

Thus the briber can be sure they'll either successfully collect the deposit, or get their bribe amount returned.

Claim 2: Will the deposit amount always exceed the potential bribe amount?

• Alice puts down a deposit of size X.
• Bob the Briber wants to buy Alice's vote for Y, where Y < X.
• Alice agrees to price Y, but doesn't want to risk losing X (a net loss).

This is per Vitalik's intended design, but Bob and Alice can trivially work around this... If Bob instead offers Alice Y + X, then Bob collects the X deposit. Thus Bob nets out -Y, Alice nets out +Y, and the deposit ended up having no effect. This assumes Bob can reliably withdraw the bribe, per Claim 1 above.

[dsernst]

If the deposit amount could be partially burned, if and only if it was being stolen, that could be a partial mitigation.

• Currently 100% of the deposit is given to the stealing briber.
• If that number was adjusted to say 20%, then the briber Bob would only get back 0.2X, and be net out -(Y + .8X), Alice nets out +Y.
• It can't be 0% or else there's simply no reason for the briber to activate the slashing mechanism.
• They could agree that Alice will absorb some of the burning costs so that they each share the 80% loss from X equally, so their net would be -(Y + .4X) for Bob and +(Y - .4X) for Alice.
• But this means X just needs to be large enough that .4X > Y, so that Alice will net out less than or equal to 0, so she has no incentive to accept the bribe.

But all this fails because now there is a public on chain record of whether the deposit was stolen or not, compromising the fundamental "unconfirmability" that MACI was trying to create in the first place. As @barryWhiteHat pointed out in the thread:

My specific concern is something like this. I deposit eth and participate in a vote. Afterwards I withdraw my ETH deposit. If this is public I can use my withdrawal transaction from public key x as evidence to a briber that I did not update my key at any time during the Vote.

It seems like a lot of these issues could be solved, and the deposit made useful again, if it could be withdrawn privately without leaking information.