Making contributions to a funding round

[auryn]

@xuhcc

Another reason for that is to design a workflow which will be compatible with the final implementation

That’s a fair point.
I’m fine with their being two transactions.
I think we should try to get users through that first transaction early, perhaps when they start adding items to their cart, so that they aren’t stuck waiting for one to confirm later.

[weijiekoh]

I chatted with @xuhcc about the idea of having a special period between the sign-up and voting periods in which only the coordinator can publish messages, and we trust them to only publish key-change messages. This would help to stave off the vote-buying attack.

We described the attack and “special period” method here:
https://hackmd.io/S7lAr3rEQhmVZO1Hhx5_Vg

I think this is useful as long as the potential victim uses a default UI that gives them access to their secret key. If only the briber has the secret key, then the method won’t work. Although it won’t solve the issue completely, a default UI would protect most users and give them a head start on bribers.

[auryn]

Is there a way to prove that the user controls both the ethereum private key and the eddsa private key?

Like a zkSNARK to prove that the user knows both the ethereum private key and the eddsa private key used to signup?

I this case, the briber would have to provide the user with the private key (or the user give the briber their private key) in order to signup.

[weijiekoh]

It’s possible to use a snark to prove knowledge of an EdDSA private key, but not for ECDSA (Ethereum) private keys. Solidity’s ecrecover can do the latter but without zero-knowledge.

I this case, the briber would have to provide the user with the private key (or the user give the briber their private key) in order to signup.

Do you mean that the “special period” method should involve the coordinator verifying that user knows the EdDSA secret key? However, the briber could generate a proof that they own the EdDSA key and instruct the user to submit that proof.

[auryn]

What I was hoping for was that we might build a signup gatekeeper that requires a ZK proof that the user controls both private keys; something that secretly combines both private keys and then provides an output that is the verifiable with the corresponding public keys.

[castall]

@auryn These latest conversation are improvements that could happen to MACI soon, but probably won’t be featured in our first few rounds because of the UI changes that would be involved, right?

[auryn]

I think it really depends on what is developed first.
If functionality like this is ready before we’ve implemented corresponding pieces on our contracts and/or frontend, then we can pivot our designs really quickly.

[weijiekoh]

In the MACI telegram group, we discussed this problem in depth. I think it’s a difficult problem and unlikely to be figured out in the near term. Moreover, implementing it would take a lot more work.

[xuhcc]

Based on the above analysis, I suggest the following plan:

Current iteration (Milestone 1): Use MACI without modifications, where it has separate sign-up and voting periods.

Milestone 3: At this point we will have to provide a nice UI, and users should be allowed to sign-up and vote at the same time, so we implement this proposal:

@xuhcc

• User calls contribute() and signs up.
• A key-change message is created and UI tells the user that the message should be submitted through the alternative channel in order to fool the briber (but we don’t enforce it).
• User submits a key-change message by calling MACI.publishMessage() .
• A batch of voting messages is created (signed with an old key in case of bribing, and with a new key otherwise).
• User submits the batch by calling submitMessageBatch() .

Our goal at this stage is to provide some minimal protection from vote-buying attacks and demonstrate how these protective measures work in the UI.

Milestone 4 or later: At this point we will allow anyone to contribute (no contributor whitelists). So we’ll need a better protection from bribery. A “special period” can be implemented assuming that it would be too hard for an average user to use keys provided by the briber:

@weijiekoh

We described the attack and “special period” method here:
https://hackmd.io/S7lAr3rEQhmVZO1Hhx5_Vg

I think this is useful as long as the potential victim uses a default UI that gives them access to their secret key. If only the briber has the secret key, then the method won’t work. Although it won’t solve the issue completely, a default UI would protect most users and give them a head start on bribers.

Hopefully some other solution will be proposed. Or a proof-of-knowledge scheme will be implemented to prevent the aforementioned attack.

[auryn]

I’m on board with this plan.

[xuhcc]

How should the voting process look like in the UI? Here’s how I imagine it (assuming contributor uses the Metamask wallet):

• User adds projects to cart, selects amounts and presses the “Contribute” button.
• The dialog window pops up and shows the progress indicator: Step 1 - Approve.
• Metamask window appears and user is asked to confirm approval transaction.
• The dialog window shows the next step: Step 2 - Contribute.
• Metamask window appears and user is asked to confirm contribution.
• The dialog window shows the next step: Step 3 - Are you being bribed? and buttons Yes and No.
• If the user presses No, the dialog window shows the last step: Step 4 - Voting.
  • Metamask window appears and user is asked to confirm voting transaction.
  • Dialog window shows Success.
• If the user presses Yes, the dialog windows shows: Step 4 - Changing the key and prints the raw transaction data along with instructions on how to submit it (through the relayer) and a button Done.
  • When user presses Done, the dialog window shows the next step: Step 5 - Fake voting.
  • Metamask window appears and user is asked to confirm transaction with invalid votes.
  • Dialog window shows the next step Step 6 - Voting and prints the transaction data and explains that real votes should be submitted through the relayer.
  • Dialog windows shows Success.

[markop]

@xuhcc So, the wizard should open as a new page clearly showing all action steps at once so that user is aware of it. Once one step is done user can move to the next.
I would hide the middle steps from the wizard progress indication. Changing the key, Fake Voting and Voting can all be grouped under “Voting” step.

[auryn]

What happens if the user starts a new browser session midway through this process (refreshes, opens on a new machine, etc)? Can they resume it where they left off? Or have they wasted the gas?

[xuhcc]

Yes, it is possible to resume the process at step 2 (if there’s enough allowance and no contribution) and 3 (if there’s a contribution but no votes).

[xuhcc]

@markop

So, the wizard should open as a new page clearly showing all action steps at once so that user is aware of it. Once one step is done user can move to the next.

I think a modal window would look better because there’s not enough content to fill a new page. Here’s a quick preview:

@markop If you have a better idea for this part of UI, could you create a mockup?

[auryn]

My preference would be to have this in some persistent element on the page, rather than a modal.

For example, this whole flow could replace the cart UI, meaning you could continue to use the rest of the page (browse projects, etc) while you wait for your transactions to confirm.

That said, the modal that you made looks fine as well.

I don’t think handing people a chunk of bytecode to send at a later date for their vote is the right UX (because of reasons*). But it’s probably fine for the test rounds.

---

Reasons

1. This pattern will almost certainly lead to phishing scams stealing people’s money, since the bytecode is pretty opaque to most users.
2. There is a really good chance people will lose that text and/or forget to post the transaction, so their votes wont count.

[xuhcc]

@auryn

I don’t think handing people a chunk of bytecode to send at a later date for their vote is the right UX

Currently there are distinct contribution and voting periods so we can’t send tx immediately after making contribution.

The final version of the UI for Milestone 3 was described in this post: Making contributions to a funding round

[auryn]

@xuhcc

Currently there are distinct contribution and voting periods so we can’t send tx immediately after making contribution.

Right, but this will change at some point, no?

@xuhcc

The final version of the UI for Milestone 3 was described in this post: Making contributions to a funding round

Yeah, I think this UX is fine for this milestone. But it can’t be the long-term solution.

[xuhcc]

@auryn

Right, but this will change at some point, no?

We already discussed it. Summary is here Making contributions to a funding round.

@auryn

But it can’t be the long-term solution.

What, exactly?

[auryn]

@xuhcc

We already discussed it.

So we did! Thanks for the reminder.

@xuhcc

What, exactly?

Defaulting to handing people a a chunk of bytecode and telling them to wait.