1.) The receiving address can implement a fallback function and attack sender
2.) Users shouldn’t interact with the Blockchain more than absolutely necessary → prone to errors
3.) He didn’t know what to do with it
Claim, give to charity or implement new functionality to send it back for a fee
1 Like
- Because they might be a malicious contract executing some nefarious logic + if you do it for a lot of people enmass, it’ll cost you lot.
- Takes more user interaction+ places costs on users+ new users can screw it up => BAD User Experience.
- He had to do something with the money left on the contract. He allowed himself access to it after a locking period of one week, but this raised an ethical/security dilemma.
- How about this: If I have to push I keep some of it. +All leftovers below a tthresholdamount are forefeited. Still doesn’t solve the security concern though. Of course he could check if the address was a contract.
1 Like
- 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?
Because new users can make more mistakes
- What problem did the writer find with people not withdrawing their money?
He did not know what to do with the money so he did a poll asking what should he do with money.
1 Like
Reading Assignment: Security vs. User Experience (Answers)
-
Sending Ether could run out of gas, sending to an unknown address could lead to security vulnerabilities.
-
User should not need really to interact with smart contract more than they have too.
-
What to do with the fund in this occurrence.
1.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.
2.What’s the writer’s argument against the “pull” design?
Pull over push is used to avoid potential code execution, fallback function (error) and possibility that send function will be executed with an error, but for many users is easier to use push (less interaction with smart contract).
3.What problem did the writer find with people not withdrawing their money?
What to do with funds participants did not withdrawal.
1 Like
1.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
2.What’s the writers argument against the “pull” design?
- people tend to make mistakes
3.What problem did the writer find with people not withdrawing their money?
- People took a long time to withdraw there money
1 Like
Sending people their eth directly has three possible drawbacks: (1) my contract might run out of gas and not be able to send the eth, (2) the tx might revert accidentally because of something on the receiver end, and (3) each time I send eth I am making a call to another address / contract, and that address / contract has the opportunity to use their fallback function to execute some other piece of code back on my contract that might be malicious.
The pull design’s main drawback is from a UI perspective - for users it’s easier to have their money sent back to them than it is to have to withdraw it. Many people simply forget / can’t be bothered to withdraw, or they make mistakes when executing the withdrawal because they are unfamiliar with how to interact with smart contracts correctly.
He found that a significant number of people either forgot to withdraw, couldn’t be bothered, or made mistakes when withdrawing their money.
1 Like
Why shouldn’t you just send people their ether directly (push)?
- Either sending ether directly to people (especially to many people) will make your transaction ran out of gas or sending ether to unknown addresses can lead to security vulnerabilities.
What’s the writers argument against the “pull” design?
- Reducing the interaction users need to do with a Smart Contract to reduce user errors.
What problem did the writer find with people not withdrawing their money?
- Finding a flexible way to return the money automatically, and letting users have the option to withdraw, and also sending it to a preset address (for a good cause).
1 Like
1 - you might run out of gas
2 - sending to unknown addresses could lead to security issues
Because people have to “pull” themselves. So some people might not remember, not care or simply don’t know how to do it
So for people who don’t withdraw, you can send the remaining balance to a known and secure address. Such as charity, or a place to hold the balance till the people ask for withdrawal
1 Like
- It can cost a lot of gas and you are sending to unknown wallets.
- It forces the user to have to interact with the SC and this comes with many other issues.
- What to do with their funds, in this case a charity was given the funds in the interim, until the users actually withdrew.
1 Like
-
Why shouldn’t you just send people their ether directly (push)?
The contract owner does not know who the recipient is. It could have a malicious fallback function or run out of gas. -
What’s the writers argument against the “pull” design?
It forces the user to have to interact with the smart contract again, making it a third time. New users are more likely to make mistakes and have issues - or just forget. -
What problem did the writer find with people not withdrawing their money?
They would take a longer time - over a week - or they just didn’t care or couldn’t be bothered. So they opted for a more flexible option, such as, the user can predefine an address on signup or donate to charity/owner.
1 Like
1. Why shouldn’t you just send people their ether directly (push)?
Many reasons, listed:
- If the push fails (for example external call can fail deliberately) it can cause security problems for the smart contract
- Some people for reason or other don´t want to withdraw their ether
- “Pull over push” pattern is argued to be favored by top reputable blockchain organizations OpenZeppelin and Consensys
2. What’s the writers argument against the “pull” design?
- It can come at cost of UX
- It might leave funds hanging, and that can cause questions what should be done to the funds
3. What problem did the writer find with people not withdrawing their money?
He was not sure where to send the remaining funds that were not withdrawn. It took very long time for the final withdrawals to happen.
1 Like
- Because the contract owner does not know who the recipient is. It could have a malicious fallback function or run out of gas.
- It forces the user to have to interact with the contract and this comes with many other issues.
- He was not sure where to send the remaining funds that were not withdrawn. It took a very long time for the final withdrawals to happen.
1 Like
Why shouldn’t you just send people their ether directly (push)?
Push introduces potential attack vectors, or could result in running out of gas.
What’s the writers argument against the “pull” design?
While safer, a pull implementation requires an extra step by the user and adds complexity to the UX.
What problem did the writer find with people not withdrawing their money?
The author found that sometimes, security competes with user experience. He was trying to find a balance between the two when deciding what to do with the unclaimed funds.
1 Like
-
The function might run out of gas especially if a lot of transfers has to be pushed. The contract is not as secure when pushing funds as when pulling funds.
-
Some people never reclaim their funds.
-
He did not know where to send the funds to.
1 Like
Why shouldn’t you just send people their ether directly (push)?
For the following reasons, you could run out of gas and more importantly, sending ether to unknown address could lead to security vulnerabilities.
What’s the writers argument against the “pull” design?
Customer experience suffers due to pull design.
What problem did the writer find with people not withdrawing their money?
They do not want to have to interact with smart contract to get paid. They wanted the process automatically. Most want the funds to go to charity
1 Like
- Because it’s never save to send value to an address you don’t know is safe
- It can run out of gas & can lead to security vulnerabilities
- He did not know what to do with the money. Send it to charity, to a specified address or back to the participants?
1 Like
Answers to the questions:
Question 1 - Why shouldn’t you just send people their ether directly (push)?
Answer:
We should never trust that a send call will execute without errors. External calls can fail accidentally or deliberately.
Question 2 - What’s the writers argument against the “pull” design?
Answer:
That a user should not interact directly with a smart contract. For the less experienced people this could lead to mistakes.
Question 3: What problem did the writer find with people not withdrawing their money?
Answer:
What to do with the money? Share or give? Or to let people withdraw by themselves, admins to send the payout back (with a fee), or give the money to a good cause.
1 Like
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 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.
What problem did the writer find with people not withdrawing their money?
More than 10% of people didn’t take within seven days.People not know what to do with it (share or give to charity)
1 Like
The SC could go out of gas + other possible vulnerabilities
It is a bad UE, the client should click less than possible. + he/she need to spend more money for gas fee
They are lazy, greedy,…
1 Like