Reading Assignment: Security vs User Experience

Ethereum Smart Contract Security Course
#22

1. Why shouldn’t you just send people their ether directly (push)?
Every ether transfer implies potential code execution and it might be malicious code and it
is a security issue. Second, your contract might run out of gas.
2. What’s the writers argument against the “pull” design?
When you have lots of new users they tend to make lots of mistakes
3. What problem did the writer find with people not withdrawing their money?
How are you going to manage the unclaimed funds?

1 Like
#23
  1. Might run out of gas, might run milicious fallback function.
  2. UX is not as good. Might result in people not collecting funds (might be inexperience, forgetfulness or simply not interested to do an extra efford.).
  3. What to do with the money: donate, take it for himself/herself or send it back with a fee in mind.
1 Like
#24
  1. Why shouldn’t you just send people their ether directly (push)?

Could run out of gas and receiving address could deliberately reply with failure (reentrancy attack)

  1. What’s the writers argument against the “pull” design?

Poor UX…people forget and make mistakes

  1. What problem did the writer find with people not withdrawing their money?

Too many ways to interact with the contract (manual interaction to withdraw). An automated way has been designed (receiving address for clear() function).

1 Like
#25

  1. You shouldn’t just send (push) funds directly because you risk running out of gas and could allow some vulnerabilities in your contract.

  2. The writer’s argument against the “pull” design consists of new smart contract users being prone to making mistakes.

  3. The problem the writer found with people not withdrawing their money is where to send their money and when (if not claimed).

1 Like
#26

1. Why shouldn’t you just send people their ether directly (push)?

  • Sending to unknown addresses is a security risk
  • When sending to multiple addresses it’s possible to run out of gas

2,3. What’s the writers argument against the “pull” design? What problem did the writer find with people not withdrawing their money?

Some people don’t claim their funds in a timely matter and others never claim it at all. The question then becomes what to do with the funds. His solution was to set a time limit on how long the user has to withdraw. After this time the unclaimed funds could be sent to a predefined address.

Synthetix does this with staking rewards. You have 14 days to claim your rewards. Any unclaimed rewards are put back into the general pool for the next staking period. There are legit reasons for not claiming the reward- i.e. the token price took a dive and the transaction costs to claim it would be more than the rewards are worth (which can happen when staking small amounts).

1 Like
#27
  1. Why shouldn’t you just send people their ether directly (push)?
    Can run out of gas - number of users can vary and code can be executed on the receiving side if it’s a contract
  2. What’s the writers argument against the “pull” design?
    User experience
  3. What problem did the writer find with people not withdrawing their money?
    What to do with the unclaimed money
1 Like
#28
  1. Why shouldn’t you just send people their ether directly (push)?
    • Because we cant assume all of them will process without an error as the receiving address can have a fallback function that can throw an error (clogging your SC). Also, external calls can fail accidentally or deliberately and you can run out of gas. And maybe you don’t actually know all the people and the addresses they want to receive ether.
  2. What’s the writers argument against the “pull” design?
    • It is not user friendly. It requires additional operations from the user and this means it is more prone to user errors.
  3. What problem did the writer find with people not withdrawing their money?
    • Users tend to be lazy or unaware, and funds are remain unwithdrawn. Then the question is what to do with that money that is fair for all (most) users.
1 Like
#29

  1. Why shouldn’t you just send people their ether directly (push)?
    You can run out of gas and sending Ether to unknown addressess can cause security vulnerabilities

  2. What’s the writers argument against the “pull” design?
    That the receiving address can implement a fallback function that can throw a error message. It`s safer to have a pull function for the funds

  3. What problem did the writer find with people not withdrawing their money?
    Some screwed up and ended up losing money, a lot of people where to lazy and some wanted to give it back or receive it automatically. It was hard to know what to do in case he took the funds and they would claim it later as many people waited a long time before claiming their funds.

1 Like
#30
  1. There is a danger of running out of gas and danger of sending to mallicous address
  2. Some users don’t know how to properly interact with smart contracts
  3. The problem for the writer was the best way to use the leftover money without big changes to the contract
1 Like
#31
  1. Push might cost a lot of gas more than available and fallback function on the receiver side contract might send error which breaks the contract.
  2. Pull is safer over push but requires a bit of efforts of participants
  3. Some people still wants the organizer send the fund back, even with small fee.
1 Like
#32
    1. Sending ether to people could run out of gas.
    2. Sending ether to unknown addresses could lead to security vulnerabilities.
  2. might cause too much errors.
  3. He got confused what to do with the money
1 Like
#33

  1. Why shouldn’t you just send people their ether directly (push)?
    – Possibility to run out of gas.
    – Security risk of sending to unknown addresses.

  2. What’s the writers argument against the “pull” design?
    – Not the greatest UX.

  3. What problem did the writer find with people not withdrawing their money?
    – He did not know what to do with it.

1 Like
#34

You shouldn’t just send people ETH directly because of the possibility of attack at the other end… which I find interesting. We received the ETH directly. We can’t be attacked receiving it?

Another reason given in this instance, with the BlockParty contract, was that sending everyone ETH could result in prohibitive gas costs/contract could run out of gas. Can’t you add ETH to a contract so that it doesn’t run out of gas?

The writer’s argument against the pull design is that so many people just don’t do it, leaving him with ETH to either donate or return. Another issue was people not familiar with smart contracts were having difficulty with the pull design. Many said they would prefer to pay a bit and have it sent.

I think that answers all of the questions?

Have an awesome day.

2 Likes
#35 
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 - e.g. via fallback function
	
2. 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
	
3. What problem did the writer find with people not withdrawing their money?
	○ what to do with the funds -> e.g. claim it, send to charity etc
1 Like
#36

  1. There are two main reasons why you should avoid sending ether from your smart contract to some other addresses. First the transaction could run out of gas. Second, because you are sending to unknown addresses there is the possibility of potential security vulnerabilities (interacting with other contracts which could do malicious exploitation).

  2. Because interacting with smart contracts is new for a lot of people, the chance that they will do mistakes is very likely. That being said the users should interact with the contract as little as possible.

  3. The author did not know what to do with the rest of the unclaimed money. He was afraid of spending the money to charity because less people could use/ interact with the smarc contract because the money is send to charity and not to random participants. He was also afraid that changing the unclaimed payout strategy could lead to less participants.

1 Like
#37
  1. Why shouldn’t you just send people their ether directly (push)? Sending ether back to participants could run out of gas, and sending to unknown addresses could lead to security vulnerabilities.
  2. What’s the writers argument against the “pull” design? Because users who are new to smart contracts tends to make mistakes.
  3. What problem did the writer find with people not withdrawing their money? Writer found in some cases it took the user 281 days to withdraw their money. Therefore, the writer suggest there should be a function called clear(), with a time limit to withdraw.
1 Like
#38
  1. Why shouldn’t you just send people their ether directly (push)?

To avoid potential reenetrancy attack.

  1. 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.

  1. What problem did the writer find with people not withdrawing their money?

He did not know what to do with it.

1 Like
#39

Because you may run out of gas of and it has some security implications.

Especially he has concerns about the user experience. People want everything to be as comfortable as possible and mostly don’t want to act by themselfes.

He had to decide what to do with this money.

1 Like
#40
  1. Why shouldn’t you just send people their ether directly (push)?

Better separation of code responsibilities and prevents attacks by the caller.

  1. What’s the writers argument against the “pull” design?

Bad for the UX, users should interact with the smart contracts as little as possible.

  1. What problem did the writer find with people not withdrawing their money?

Where to leave the money

1 Like
#41
  1. Why shouldn’t you just send people their ether directly (push)?

Pushing can leave the calling contract vulnerable to reentry attacks from untrusted contracts.
Sending to all users contracts uses up too much gas.

  1. 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.

  1. What problem did the writer find with people not withdrawing their money?

What to do with the money left over.

1 Like