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.
It says right here “please send this transaction… after 2020 Aug 28”
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.
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.
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.)
@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.
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.
@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.
What does this look like in practice for someone who has been bribed?
It should look like this:
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?
There are still two periods, signup period and voting period (though this naming is not quite correct). A user can submit messages during the signup period, but these messages are processed after the messages submitted during the voting period. So when signup period ends, user can secretly change the key and everything submitted during the signup period becomes invalid. I think the briber can still try to force user to vote and invalidate key again immediately after the beginning of the voting period, but it is hard to do and the current MACI implementation is also vulnerable to it.
Right, this is what I’m suggesting. The briber would just force the user to create a valid message that they can broadcast in the first block after the voting period ends. In which case, there is a race condition between the briber and the user to get their transaction into that block (and ordered first in the block). The briber is probably better equipped to make that happen.
great! , It would be a great idear, I support!