Are you ready for the next Reading Assignment?? I hope so, because here it is! This time about the compromise between user experience and contract security. Read through this blog post and answer the following questions in this forum thread.
Why shouldn’t you just send people their ether directly (push)?
could a malicious contract, contract might not be ready, the end user may not want it or nor wnat to take part in the place.
What’s the writers argument against the “pull” design?
new user error or user error. but 10% take greater than a week to claim only 10% actually claimed within that time period a week
What problem did the writer find with people not withdrawing their money?
claim process or designation could be different e.g. a charity and also dependant on winner whether they wanted to participate etc…
Sending ether back could run out of gas. Sending ether to unknown addresses could lead to security vulnerabilities.
Users new to smart contracts ten to make mistakes.
Problem was what to do with the money.
- Why shouldn’t you just send people their ether directly (push)?
Due to possible malicious attempts of reentrancy attack.
- What’s the writers argument against the “pull” design?
Poor UX for end users. The users fear to make a mistake.
- What problem did the writer find with people not withdrawing their money?
Many of them did not bother to widthraw their deposited funds as they were “lazy”. Some of them are willing to pay for “automatic refund”.
The users had to interact too many times with the “BlockParty” service
Why shouldn’t you just send people their ether directly (push)?
Sending to many people can end up complete transaction, because running out of gas.
Another thing is possible malicious reentry attack, when sending on unknown address which is contract.
What’s the writers argument against the “pull” design?
Users are lazy, also some have fear and they don’t want to again interact with contract.
They also tend to make mistake when again interacting with contract.
What problem did the writer find with people not withdrawing their money?
What to do with money leftover, should it be sent to charity, taken by himself
or returned to sender with (push) and opened security vulnerability because of that
Why shouldn’t you just send people their ether directly (push)?
Could run out of gas and opens contract to security issues.
What’s the writers argument against the “pull” design?
More interaction with a contract can cause inexperienced users to make mistakes
What problem did the writer find with people not withdrawing their money?
It is tied to the incentive of people showing up changing the payout mechanism may dilute the unique and strong message BlockParty has.
Pushing funds directly to users, or external contracts, can lead to more security vulnerabilities and potential errors than allowing people to pull their funds with an separate function they can call themselves. It’s also possible to run out of gas before you the function pushing funds back to recipients is completed, resulting in additional, unintended errors.
He argues that the pull design is not as user friendly. In particular, people new to smart contracts are more likely to make mistakes if they have more opportunity to interact with the smart contract. Therefore, the less people need to interact with the smart contract, the better.
It was left in the smart contract and was given to the smart contract owner after the default cooling period he set. In avoiding the security risks by using pull over push, he found himself with 10% of the original deposits not being collected and left in his possession. While this doesn’t seem like a very bad problem to have, he requested suggestions from the community on how best to disperse the remaining funds. Final solutions included sending it back to recipients with an admin fee, sending it to a predefined address like a charity, letting the contract owner keep it, and retaining the withdraw function.
What’s the problem with leaving the funds in the smart contract until users come back to withdraw the funds? He could just remove the clear function so the funds remain available for withdrawal indefinitely.
Sure, it’s a waste for the money to sit there, and after a certain point something should probably be done. But is there any harm or potential risk to the contract in leaving the funds unclaimed?
What’s the problem with leaving the funds in the smart contract until users come back to withdraw the funds? He could just remove the clear function so the funds remain available for withdrawal indefinitely.
Yes, that’s correct. There is no harm. But many projects want their tokens and users to be active. So they put in different measures to motivate their users to act in certain ways. And in this case, the author wants to make a point regarding push/pull. Many people think that the contract could simply pay out the balances when they expire, but that’s risky as we saw in the article.
1 - you expose to some malicious callback functions
2 - user inexperience
3 - what to do wiht the money
What’s the writers argument against the “pull” design?
Every Ether transfer implies potential code execution. The receiving address can implement a fallback function that can throw an error. Thus, we should never trust that a send call will execute without error. A solution: our contracts should favor pull over push for payments.
What problem did the writer find with people not withdrawing their money?
More than 10% of participants do not withdraw their payout within 7 days. The problem is - What to do with it?
1.Why shouldn’t you just send people their ether directly (push)?
Sending ether back could run out of gas and/or lead to security vulnerabilities.
2. What’s the writers’ argument against the “pull” design?
Users may have a fear of and/or make mistakes when interacting with a smart contract.
3. What problem did the writer find with people not withdrawing their money?
What to do with the un-withdraw amounts (without push/ send people their ether directly).
Security vs User Experience
1. Why shouldn’t you just send people their ether directly (push)?
Cost more gas to complete this transaction. User pull function uses less gas and isn’t prone to malicious virus being downloaded into the contract.
2. What’s the writers argument against the “pull” design?
Limit the user interaction with the contract as much as possible because users tend to make mistakes.
3. What problem did the writer find with people not withdrawing their money?
10% of the users didn’t withdraw their admin fee within 7 days. The writer needed to create a rule to manage unclaimed funds.
You can run out of gas and secondly, probably more important, the other adress (maybe a smart contract) could execute code with a fallback therefore the security risks will be too high.
Users should not really need to interact with smart contract more than they absolutely have to as people new to Smart contract tend to make mistakes.
However, I have a bit of concern that donating the no show deposits to charity actually weaken people’s will to turn up because it goes to a good cause rather than random participants. Also, changing the payout distribution logic depending on events may dilute the unique and strong message BlockParty has.
Why shouldn’t you just send people their ether directly (push)?
Sending ether back to all the participants could run out of gas, Sending ether to unknown addresses could lead to security vulnerabilities.
What’s the writers argument against the “pull” design?
Users may have a fear of mistakes when interacting with a smart contract.
What problem did the writer find with people not withdrawing their money?
They do not know what to do with it.
Sending ether back to all the participants could run out of gas and sending ether to unknown addresses could lead to security vulnerabilities.
It is a bad user experience since users may be able to get confused cause they may screw up something or they just forget.
He has to come up with an idea about what to do with the money of the people who didnt withdraw.