Making contributions to a funding round

general
#51

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.
#52

@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.

1 Like
#53

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?

#54

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).

1 Like
#55

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

Peek 2020-08-28 21-09
Peek 2020-08-28 21-09915×542 932 KB

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

#56

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.
#57

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

#58

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

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

#59

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

What, exactly?

#60

So we did! Thanks for the reminder.

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

#61

Nowhere in that post I did say that we should tell people to wait. Users will probably need to wait for transactions to confirm at steps 1 and 2, but that’s a normal situation for dapps.

The bytecode should be displayed somewhere at steps 4 and 6 in the scenario with a bribe because user may want to submit transaction from another account instead of sending it to relayer.

#62

It says right here “please send this transaction… after 2020 Aug 28”
image
This is telling users to wait.

The bytecode should be displayed somewhere at steps 4 and 6 in the scenario with a bribe because user may want to submit transaction from another account instead of sending it to relayer.

I agree, this is probably a necessary evil. But the happy path probably has no need to hand user bytecode.

In the case that the user is being bribed, couldn’t we give the user all of the parameters they would need to submit from another address, rather than the bytecode? This could even be a json file or something that the app facilitates sending. So the user can switch accounts, pass it to a friend, or give it to a relayer to send.

#63

We’ll use this kind of UI only for testnet rounds. I already explained why we can’t submit tx immediately at the current stage of development and gave you a link to the description of how the final version UI will look like at Milestone 3. If you have further questions, ask them in chat.

What parameters? To send an ethereum transaction user needs a contract address and raw transaction data, and that’s exactly what we are giving them. A user just needs to copy-paste tx data and contract address to the wallet UI.

#64

Yeah, that modal is fine as well, everything is on the same screen and moving forward through steps seems faster. I’d be ok leaving it as is but definitely consider revisions based on the discussion below (handling bytecode, waiting time etc.)

1 Like
#65

@markop What do you think about placing the wizard inside right side bar as Auryn suggested?

This would make sense if we deploy clr.fund to mainnet where transactions can take a long time to confirm. But if we deploy to sidechain/rollup we probably won’t have this problem. If moving through the steps happens quickly I would prefer modal because it better captures user’s attention.

1 Like
#66

The cart could easily be replaced with the modal and it will grab the same user attention since it will replace something already existing on the screen, have a loader etc. soon after that user already knows things are happening in that area.
Similar to MM modal when you have to multiple times approve something (view wallet, approve spend, sign transactions).

I’m ok for keeping it as is now in the modal if it’s going to be deployed on a sidechain, or if it’s not much of an effort to move it to the sidebar Cart right away. I’d let you make that decision based on dev other priorities.

2 Likes
#67

@barryWhiteHat recently suggested a better solution to the problem of vote buying. The idea is that we allow users to vote immediately after signup but we delay the processing of messages submitted at signup until the end of the voting period. Even if briber gives user a private key and asks her to vote and then invalidate the key, a user can override these commands later during the round:

This solution should give us better UX while keeping MACI safe from vote-buying attacks.

#68

What does this look like in practice for someone who has been bribed?

#69

It should look like this:

  1. Contribute to the round using your own key.
  2. Submit message with the vote and change the key to invalid key as the briber demanded.
  3. Show proofs to the briber and get the money.
  4. Return later, change key you used at signup to another valid key and vote for the projects you prefer, overriding the previous votes.
#70

But you can’t change the key until the voting period, right?
Doesn’t this just create a race condition between you and the briber?