1. Why shouldn’t you just send people their ether directly (push)?
The receiving address could be malicious and can implement fall back function with can throw error or it can run out of gas.
2. What’s the writers argument against the “pull” design?
That users shouldn’t interact with smart contract if its not necessary because new people tend to make mistakes.
3. What problem did the writer find with people not withdrawing their money?
People wasn’t withdrawing it in space of 7 days (cooling period) and some of them wasn’t withdrawing at all.
Problem was that what to do with this left over money.
1 Like
-
Because it could be run out of gas and could cause malicious security risks.
-
User is afraid of making mistakes upon dealing with smart contracts or he/she is lazy.
-
How to behave against unclaimed funds.
-
Why shouldn’t you just send people their ether directly (push)?
Because the transaction could run out of gas and sending ether to unknown addresses could lead to security vulnerabilities. -
What’s the writers argument against the “pull” design?
That users should not really need to interact with smart contract more than they absolutely have to as people new to smart contracts tend to make mistakes. -
What problem did the writer find with people not withdrawing their money?
The problem the writer had was with what to implement in his smart contract with regards to what to do with the unclaimed money.
- The transaction could run out of gas and there is a risk of re-entrance attacks
- People are lazy or they simply don’t know how to do it
- He didnt know what to do with the money that was left over.
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. The receiving address can implement a fallback function that can throw an error, so we can not trust that a send call will execute without error. External calls can fail accidentally or deliberately. To minimize the damage caused by such failures, it is often better to isolate each external call into its own transaction that can be initiated by the recipient of the call. By default, the contract has to pay the gas for a push transfer.
2. What’s the writers argument against the “pull” design?
The user experience could get whorse. If there are more than one step a user has to perform in sequence, the user might forget to perform some of the steps. Users should not really need to interact with smart contract more than they absolutely have to, otherwise the risk to make mistakes increases.
3. What problem did the writer find with people not withdrawing their money?
The users forget to perform the withdraw (in time). The contract then has to decide what to do with the remaining funds. Should the contract hold the funds foreever or release them after a set period of time? If the former, the contract cannot be deleted and it’s resources cannot be released even if the initial porpose doesn’t exist any more. If the latter, should the contract owner be able to receive all left funds or should the contract donate to a DAO? Afterwards the user might complain, that his left funds are not accessable any more.
1 Like
-
Why shouldn’t you just send people their ether directly (push)?
Because it costs money and thus there is a risk of not having sufficient gaz. Plus, it makes the code more complex, exposing the contract to a security bug. -
What’s the writers argument against the “pull” design?
it adds friction to the user experience. -
What problem did the writer find with people not withdrawing their money?
How to deal with this surplus of money.
1 Like
- Why shouldn’t you just send people their ether directly (push)?
You are more likely to run out of gas, any exception thrown in external contract (if using transfer will revert transaction), simpler code give less room for mistake. - What’s the writers argument against the “pull” design?
Participants are forced to interact with contract to pull funds. - What problem did the writer find with people not withdrawing their money?
Participants might not claim their funds. Then it’s a question what should be done with leftovers.
1 Like
- Because letting the contract deal with the gas will inevitably cause to run out of it and therefore, it could break the contract and cause a lost of funds. Even dealing with error handling would not be that simple.
- The point against Pull request was that users are either Lazy or dont’ really now how to interact with the smart contract.
- He didn’t know what to do with the funds.
1 Like
- Why shouldn’t you just send people their ether directly (push)?
Receiver might be malicious, call back function might try do something unexpected, gas limits. - What’s the writers argument against the “pull” design?
Make the user experience more user friendly, why make a user take extra steps. Many people are new and might not withdraw. - What problem did the writer find with people not withdrawing their money? Had to decide what to do with it. Returning it costs gas which would have to be charged to the user. Also who to send it to, keep it vs charity etc
1 Like
-
Why shouldn’t you just send people their ether directly (push)?
Sending funds to a unknown source bears the risk of code execution triggering a fallback function which may have malicious intend or contains in itself a bug causing potential risk for the contract. Also the automatic send could run out of gas. -
What’s the writers argument against the “pull” design?
Increased user experience. Limit the number of times a user has to interact with a smart contract as many people are lazy or new users tend to make mistakes (are overwhelmed). -
What problem did the writer find with people not withdrawing their money?
What to do with the left over funds? Send to charity, return with an administration fee or keep?
2 Likes
- Why shouldn’t you just send people their ether directly (push)?
- Contract may run out of gas;
- Sending to unknown addresses may be insecure.
- What’s the writers argument against the “pull” design?
- New users may make mistakes when interacting with the smart contract.
- What problem did the writer find with people not withdrawing their money?
- The choice to keep it, send to users, or send to charity.
1 Like
- Sending Ether back to all of the participants could run out of gas and sending Ether to unknown addresses could lead to security vulnerabilities
- The pull design adds an additional step to the user interaction. Some participants forget to withdraw their funds or are too lazy to do so.
- A problem arose regarding what to do with the unclaimed deposits. Sending Ether back to all participants could be too costly and donating to charity actually weakens people’s desire to show up because it goes to a single good cause instead of random participants. Also, changing the payout mechanism too much may dilute the premise of Blockparty as well (“You will get deposit +more [aka. payout] if you attend”).
1 Like
-
Sending ether to a large number of people could result in gas shortage.and security issue.
-
The pull design hinders the user experience. Users have to interact more with the smart contract which can leads to errors.
-
The writer felt confused about what to do with the leftovers
1 Like
Hello from Mexico, 
- Why shouldn’t you just send people their ether directly (push)?
- Sending Ether directly increases code vulnerability because we are sending to an address that is stored programmatically by our code. In constrast, when letting the user call a withdraw() function, the address is safely identified by msg.sender.
- In a situation where sending Ether is done within a loop, there is a risk that the transaction runs out of gas.
- What’s the writers argument against the “pull” design?
- The downside of the pull design is that it brings additional hassle to users. Instead of being automatically credited, they have to take action to withdraw. The author pointed out that in his experiment, a percentage of participants simply cannot be bothered withdrawing their gains.
- There is also an issue with the gas fees incurred by people when withdrawing.
- What problem did the writer find with people not withdrawing their money?
- In his experiment, the author found that 10% of participants didn’t take their money after 7 days. Among the reasons shared by users were:
- Extra hassle
- People new to smart contracts tend to make mistakes when making calls
- High gas fees
As a user I don’t really have a problem with being asked to withdraw myself. An example of this use case is the Brave browser that notifies you about your BAT rewards. You then have to click the Claim Rewards button to receive your BATs. Because the UX is well done, I find this creates more excitement than hassle.
1 Like
- would cost us gas and sending ETH to an address (which could be an another contract) increases the risk of malicious activity (for example: the address we are sending it to is a contract that executes malicious functions and call another function within our contract)
- it requires more input from the users and they can get too lazy to clam it (which is crazy btw) + they might make mistakes
- what to do with the unclaimed funds?
1 Like
- It costs you gas to send it to them and if you have a large number of addresses then it could run out of gas. In addition it allows them the opportunity to potential submit a re-entrancy attack on that function if they deliberately fail the function execution.
- It requires the user to interact more with the contract than possibly necessary and if the user interacts incorrectly then that can lead to undefined behavior. By automating it in a push function UI ease of interaction increases.
- Sometimes they were just lazy, but then the question becomes what should be done with the funds that aren’t withdrawn. That is a crucial question as everyone has a different opinion on what should be done with the money.
1 Like
- Why shouldn’t you just send people their ether directly (push)?
It is because sending ether back to all the participants could run out of gas. Also sending ether to unknown addresses could lead to security vulnerabilities. - What’s the writer’s argument against the “pull” design?
It’s a problem from a user experience point of view, that they have to remember it pull their fund out. Only 10% of users pulled their funds in 7 days period. - What problem did the writer find with people not withdrawing their money?
The problem was that people were lazy, and only 10% withdraw their funds, the problem was also what to do with leftovers after 7 days period.
1 Like
-
Why shouldn’t you just send people their ether directly (push)?
Well there are multiple opinions but primarily because of- The direct push operation can burn more gas
- The chances of unknown address receiving payments
-
What’s the writers argument against the “pull” design?
His main argument was push operation causing more gas consumption -
What problem did the writer find with people not withdrawing their money?
- The multiple requests would result in errors
- Multiple people won’t just withdraw money in timely fashion so he had to implement logic to clear the balance after certain time period.
1 Like
Why shouldn’t you just send people their ether directly (push)?
- External calls can fail accidentally or deliberately and can cost more gas.
What’s the writers argument against the “pull” design?
- Not many people withdrew their funds in a reasonable time.
What problem did the writer find with people not withdrawing their money?
- What to do with the funds after a period of time has gone by.
1 Like