- You should not send ETH directly because it is better to spread the code out then keep it within the same logic. Another big reason is that it is better to put the gas responsibility on the user, modularize your code, and have your checks, effects, interaction pattern in place to fight off re-entrancy attacks.
- It makes the user experience more complicated then it needs to be.
- The decision of what to do with the funds, either give it charity, keep it in owner’s account for fees, or give it to a random participant, thus continuing to incentivizie participants.
1 Like
-
Sending people their Ether directly costs gas and the call may run out of gas when sending many transactions. If the task is split up into multiple functions then it minimises the risk of running out of gas.
-
The writer says that when using the pull design, there is a trade off of user experience. Many users don’t withdraw their Ether or are new and don’t understand enough. It also creates another step for the user.
-
The problem the writer had with people not withdrawing their money was that it could be going to him or charity instead of sitting in the contract.
1 Like
1. Why shouldn’t you just send people their ether directly (push)?
It is unreliable every value transfer could throw an error
2. What’s the writers argument against the “pull” design?
Contract members are too lazy and don’t withdraw they funds for long period of time. Some people may have low balances and it could be just not profitable for them to do a transfer(especially in may 2021 
)
3. What problem did the writer find with people not withdrawing their money?
Small part of people don’t withdraw they money and money become completely unused. Author was concerned about that fact. Actually i don’t see any issue with this at all 
1 Like
1. Why shouldn’t you just send people their ether directly (push)?
i) Security risk - its’ harder to identify, understand and protect/test against all possible attack vectors (as the code is less modular and therefore complex - especially when coupled with malicious contracts fallback functions attempting to exploit the contract).
ii) The paying contract will need to cover the gas cost and if insufficient gas is provided by the contract the transfer to the payee(s) will fail.
iii) If a payee is a (non-malicious) contract but it’s payment receiving fallback function errors, then the payee will not receive the payment
2. What’s the writers argument against the “pull” design?
i) That users need to perform another action (i.e. explicitly requesting payment) - which is bad UX. And people can also make mistakes trying to withdraw their funds themselves.
ii) That about 10% users don’t actually claim their payout despite being entitled to it.
iii) The sum of the individual transaction fees born by the user (with a pull design) are typically higher than employing a push design (to send all user’s their payments automatically).
3. What problem did the writer find with people not withdrawing their money?
The issue of what should be done with unclaimed payouts (which by default will remain in the smart contract). This becomes more of a dilemma, as when the users were polled ton what they would prefer there was no clear consensus (eg. leave funds in contract, give funds to owner, give funds to charity).
1 Like
- Why shouldn’t you just send people their ether directly (push)?
“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. This is especially relevant for payments, where it is better to let users withdraw funds rather than push funds to them automatically. (This also reduces the chance of problems with the gas limit.) “
- 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?
When he asked whether users want smart contract to send the money back (with extra admin cost) while over 50 % of people were up for the idea (26% yes + 15.8&5.3% yes if cheap), 30% of people said that they would rather do it by themselves.
1 Like
- Why shouldn’t you just send people their ether directly (push)? — can run out of gas and risk transaction failure, also sending to unknown addresses has security risk
- What’s the writers argument against the “pull” design? — people shouldn’t / don’t want to interact with smart contracts more than they have to, sacrifices UX, and users may mess up
- What problem did the writer find with people not withdrawing their money? — very mixed responses
1 Like
- Why shouldn’t you just send people their ether directly (push)?
- Function may run out of gas
- Security vulnerabilities when sending to unknown addresses
- What’s the writers argument against the “pull” design?
User Experience gets worse. They have to perform more steps and are more prone to mistakes. - What problem did the writer find with people not withdrawing their money?
What to do with those funds.
1 Like
1: The contract address could be malicious or a threat to re-entrency attacks!
2: Poor UX for end-users. New people to smart contracts tend to have more bugs.
3: The money will just sit in the smart contract and not be used therefore wasting it essentially if nothing is done.
1 Like
-
You shouldn’t use push because you could run out of gas and sending ether to unknown addresses could lead to security vulnerability.
-
For the end-user, push design is preferred over pull. Users don’t have to withdraw by themselves.
-
The problem that occurred people not withdrawing their money is what to do with the money. Share or donate to charity?
1 Like
- may run out of gas or introduce a vulnerability or fail in the fallback function
- users need to follow the steps, of which some may forget or not know
- users shouldn’t interact with contracts more than they need to. by giving their money to others, it doesn’t enforce the users to show up
-
The push method has no Error handling . The contract could be sending funds to another malicious contract which may try to change this Current contract’s control flow using Fallback Functions, or it may fail in its own fallback functions or the transaction may run out of Gas.
Or even in the case it’s a User account, the transaction could consistently fail (without the contract knowing it) and hence resulting in repeated gas costs. So therefore, it’s always better to use Pull contracts with Mappings ( let the user withdraw and then allow the Mappings to change state variables and hence know of all the send / receive activities happening in the contract. They could further also be emitted as events which are then permanently stored on the Blockchain).
So Pull is a Safer/ Secure method (which doesn’t allow Re Entrency attacks if code is properly written) even if its lengthier and not that much UI friendly , alsoModularises the contract into different functions and Modularisation is Better Standard/ Practice as per Consensys/ General Software rules. -
The Pull design (Specifically in the case of this Contract in the Blog Post) was tedious and not UI friendly. The Users were too lazy to withdraw funds and hence it posed Philosophical Questions to the Contract owner on how to design his contract ( whether to withdraw himself after eventEnd or to give unused funds to Charity etc…)
-
The problems are philosophical : Whether to withdraw Himself, or to send to Charity, or to send to customers using the address.transfer or address.send Push Methods after the Expiry of the endEvent Time (& if using such Push methods, who shall be paying for the gas Costs etc…) ?
1 Like
-
Its because sending ether back to all the participants could run out of gas and at the same time sending ether to unknown addresses could lead to security vulnerabilities.
-
The writer’s argument against pull design was that 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.
-
For me what the writer saw with people not withdrawing their money is that he is more concerned that the funds will only be stuck there and be wasted, that’s why he did change the clear() rule with the alternatives that gives the maximum preferable option for the people to withdraw it by themselves, with only a little change on the smart contract itself.
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?
- Because the smart contract has a function called clear() which allows contract owner to take all the left over and the default cooling period is set to 1 week.
1 Like
-
Why shouldn’t you just send people their ether directly (push)?
Because of the possibilities of running out of gas and security vulnerabilities introduced when sending to unknown addresses.
-
What’s the writers argument against the “pull” design?
Because users who are new to smart contracts will make mistakes.
-
What problem did the writer find with people not withdrawing their money?
The writer faces a situation in which there are different options to deal with the money, e.g. send them back to the participants with a fee, give to charity, take the money himself, or leave it there forever; each with pros and cons.
1 Like
- Why shouldn’t you just send people their ether directly (push)?
Because maybe you are running out of gas and security problems. - What’s the writers argument against the “pull” design?
users can make mistakes with the smart contract, fewer interactions with the smart contract its better for user experience. - What problem did the writer find with people not withdrawing their money?
The problem is what to do with the money.
1 Like
-
You shouldn’t just send people their ether via push because the transaction could run out of gas, and sending to unknown addresses leaves the contract open to vulnerabilities.
-
The writer’s argument against pull design is that it gives a poor UX for the users as it makes them interact more than they should which causes mistakes.
-
The writer found that people did not bother to withdraw their funds because they were being lazy, and not wanting to have to interact with the contract more. This led to a greater problem as to what to do with the unclaimed funds.
1 Like
1- Push functions may lead the contract being out of gas, and open for re-entrency attacks.
2- People new to smart contract tend to make mistakes.
3- People being too lazy to withdraw their funds, and it being led to a greater problem which is the unclaimed funds, and what to do with them.
1 Like
1 You shouldn’t just send people their ether directly because external calls can fail accidentally or deliberately and it is best practice to isolate each external call into its own transaction which is much easier and safer to have the user do themselves.
2 The writers argument against the “pull” design is that people tend to make mistakes so they should be interacting with the smart contract as little as possible.
3 The problem the writer found with people not withdrawing their money was that some people were lazy but still wanted their payouts, some people wanted the contract to send it back automatically, and some wanted to pull their funds themselves. In an attempt to satisfy all of his users he added functions to execute whichever process the user preferred.
1 Like
1. Why shouldn’t you just send people their ether directly (push)?
2. What’s the writers argument against the “pull” design?
3. What problem did the writer find with people not withdrawing their money?
- security concerns (external call can throw an error), call could run out of gas, less modular code
- worse user experience. New users tend to make mistakes.
- what to do with unclaimed funds (10% of users)
1 Like
-
Why shouldn’t you just send people their ether directly (push)? First, you could run out of gas (ether). Second, there are security vulnerabilities that are beyond your control (reentrancy attacks).
-
What’s the writers argument against the “pull” design? Some people are ‘newbies’ when it comes to the blockchain and smart contracts and should not interact with smart contracts more than necessary. They may make mistakes that could decrease their ether/funds when trying to ‘pull’ back funds.
-
What problem did the writer find with people not withdrawing their money? Those people were lazy and just left their money there. Additionally, there was no strong consensus of what to do with the funds that weren’t withdrawn.
1 Like