- Why shouldn’t you just send people their ether directly (push)?
Because there is a risk of running out of gas and it’s a big security risk and pull functionality is considered best practice right now - What’s the writers argument against the “pull” design?
Individuals are having to interact with the contract/app multiple times which could potentially cause friction with ease of use. In this article they have to interact 3 times and perhaps that’s too much. - What problem did the writer find with people not withdrawing their money?
What to do with the funds when they are not withdrawn and where to send it to.
1 Like
1. Why shouldn’t you just send people their ether directly (push)?
Sending back funds could run out gas or allow to exploit your own code, therefore lead to security risks.
2. What’s the writers argument against the “pull” design?
The more interaction with smart contract is required from users, more discomfort it will cause which lead to errors. A minimalistic interaction is more desirable.
3. What problem did the writer find with people not withdrawing their money?
People tend to be lazy or unaware how to withdraw the money. The main question is how to handle properly this leftovers.
1 Like
1. Why shouldn’t you just send people their ether directly (push)?
Reasons include:
- your function running out of gas (especially if the logic before the send is complex and there are many transfers that need to take place)
- sending to unknown addresses poses a potential security risk
- the transfer of funds will have its own transaction hash and therefore can be more easily identifiable/traceable, especially if there is an issue
2. What’s the writers argument against the “pull” design?
A user should not need to interact with a Smart Contract more than necessary and beginners to block chain could make mistakes.
3. What problem did the writer find with people not withdrawing their money?
The contract has a clear() function which allows the user to sweep any left over funds after a set period (in this case 7 days). Different solutions to how to handle the unclaimed funds all have potential upsides and downsides.
1 Like
- Why shouldn’t you just send people their ether directly (push)?
- because you could run out of gas Ether, and sending ether to unknown addresses could lead to security vulnerabilities.
- What’s the writers argument against the “pull” design?
- Expecting the users to pull their funds creates a poor user experience, they expect things to happen automatically.
- What problem did the writer find with people not withdrawing their money?
- Some people were not withdrawing their money for a significant period of time, or even not at all
1 Like
- Why shouldn’t you just send people their ether directly (push)?
you may be sending to a contract address which pulls an error/or tries to call a function. also to avoid gas transaction issues
- What’s the writers argument against the “pull” design?
degrades the user experience, people will leave their funds their for long periods of time
- What problem did the writer find with people not withdrawing their money?
some people waited for very long periods of time before withdrawing
1 Like
-
Why shouldn’t you just send people their ether directly (push)?
because there are safety issues (we don’t know if by pushing to some user we could fire a fallback function) and because there is a gas consumption issue -
What’s the writers argument against the “pull” design?
user experience would be better if the smart contract would return automatically the money
- What problem did the writer find with people not withdrawing their money?
almost half of the people would not withdraw their money and therefore there is the issue related with what to do with this money left in the contract
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 and sending ether to unknown addresses could lead to security vulnerabilities.
2) What’s the writers argument against the “pull” design?
He ran statistics to show that a significant number of users would not pull their funds, so for them that would be a bad UX not receiving the funds automatically.
3) What problem did the writer find with people not withdrawing their money?
He ran another poll to determine what to do with the remaining funds. The options were:
- Leave funds forever
- Send them back
- Keep himself
- Send to charity
IMO he could have also asked to burn the funds which would have a positive effect on inflation.
1 Like
- Why shouldn’t you just send people their ether directly (push)?
- You risk running out of gas.
- It could lead to security vulnerabilities.
- Minimize the damage caused by such failures.
- What’s the writers argument against the “pull” design?
- It makes working with the contract more complicated.
- Not as user friendly.
- What problem did the writer find with people not withdrawing their money?
- Deciding what to do with the money left in the contract.
- (He lacks executive decision making skills, 25% to make app improvements, 75% evenly distributed to attendees, done, give me the next problem.)
1 Like
- Because you never know if it is an external address really or a contract address that could have a malicious fallback function / also it could run out of gas
- Should minimize number of times user has to interact with contract, and also some people make mistakes with this or get confused
- People are lazy and/or find it inconvenient and a percentage of them never request their money - he was trying to find the most acceptable option as far as how to handle that unclaimed money that would be satisfactory, while still incentivizing those people to attend the events
Why shouldn’t you just send people their ether directly (push)?
Sending ether back 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 and/or make mistakes when interacting with a smart contract.
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.
1 Like
1. Why shouldn’t you just send people their ether directly (push)?
This is prone to attacks from malicious contracts and actors. They can run code upon receiving the pushed funds and run a fallback function deliberately throwing an error.
2. What’s the writers argument against the “pull” design?
People can forget to withdraw their money in a separate call to a withdraw function. If pushing then it would improve the UX.
3. What problem did the writer find with people not withdrawing their money?
They found that about 10% took more than a week to withdraw and that some never did.
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?
user experience for the users - refund automatically would be better (even with a higher price and users will not forget to withdraw) -
What problem did the writer find with people not withdrawing their money?
more than 10% of people didn’t take the payout within seven days; there is a question what to do with unclaimed money (keep the money, leave in the contract, send back, charity)
1 Like
1; There is always danger in sending ETH to an unknown address
2; The writer argues “user error” common.
3: It says unclaimed funds will be allocated to charity within a 1week period.
-
You shouldn’t just send people ether directly (push) because:
- it creates a security risk; it opens your contract up to re-entrancy attacks from external contracts which you have no control over;
- it costs you gas, and if you are using a single function to send ether to multiple people, you run the risk of running out of gas and the ether not being sent. -
The argument against the pull design is that it can result in a negative user experience:
- some users can be too lazy, or forget to withdraw their funds;
- some users may find it difficult to withdraw their funds due to a lack of knowledge about smart contracts, or they may make mistakes. -
The problem created by people not withdrawing their money is what to do with those funds:
- Transfer it to the contract owner?
- Return it to the users using the push design? An admin fee could be deducted from the amount returned, in order to offset the gas cost and the increased security risk; but user opinion is divided over how much this deduction should reasonably be.
- Donate it to charity? This is a popular option, but could weaken the incentive for those who have registered, and paid a deposit, to actually attend the event, thereby defeating the objective of the smart contract in the first place.
A further issue is how long to wait before executing one of these different options. And instead of just one of the above options being adopted, users could choose which one they prefer when they register. So, the decision about what to do with funds that haven’t been withdrawn is a complex one, and this in itself is problematic.
1 Like
- Why shouldn’t you just send people their ether directly (push)?
- Sending ether from contract to address costs the contract gas, vs pull costs recipient the gas
- Sending eth to unknown addresses can cause security vulnerabilities
- Every eth transfer implies potential code execution. The receiving address can implement a fallback function that can throw an error.
- 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?
- Users not withdrawing their money, would rather pay extra to someone else or the contract so the money is sent back automatically.
1. Why shouldn’t you just send people their ether directly (push)?
Because it can lead to issues such as running out of gas and most importantly lead to security vulnerabilities for the contract, considering an external address could have some kind of fallback call which executes in the event of receiving funds from a given contract. This could alter how the function from the contract works in a harmful way.
2. What’s the writers argument against the “pull” design?
People do not know how to operate such call to withdraw their funds and since they have to withdraw it themselves means a poor user experience.
3. What problem did the writer find with people not withdrawing their money?
There were many people who did not withdraw their money for more than 7 days and so those funds remained dormant.
- 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?
UX experience is worse, since it requires more interaction with the contract on the userside.- What problem did the writer find with people not withdrawing their money?
What to do with unclaimed funds.
Q1. Why shouldn’t you just send people their ether directly (push)?
a. Sending ether back to all the participants could run out of gas.
b. Sending ether to unknown addresses could lead to security vulnerabilities.
Q2. What’s the writers argument against the “pull” design?
Users do not have experience in interacting with smart contracts and can make mistakes in pulling their funds.
Q3. What problem did the writer find with people not withdrawing their money?
The problem was what to do with the leftover funds. Whether to:
a) contribute to charity or
b) take the leftover funds as contract owner or
c) distributing among participants (thus increase security risk)
-
It can lead to a security flaw as the address (we are interacting with) could be a malicious contract which could have a function that can be harmful.
-
It can lead to poor user experience as people new to crypto can often make mistakes.
-
That some people did not withdraw money for over seven days, and there is a confusion as to what to do with unclaimed money.
- Send Ether back could run out of gas, send to unknown address could lead to security issues.
- Users may do errors as not experience in smart contracts.
- What to do with it? Although survey response was a nice way to solve it, charity was a final good choice…
1 Like