Reading Assignment: Security vs User Experience

Ethereum Smart Contract Security Course
#202
  1. Because the function might run out of gas in case of a dynamic array and because of security issues as yo don’t know who you’re transferring to.
  2. It’s more from a user experience POV as some users wanted to have their funds automatically transferred to them, considering they will have to pay an additional fee and also because some smart contracts have time locks that prevent the users from retrieving their funds in case of a limited withdrawal period.
  3. Laziness/forgetfulness.
2 Likes
#203
  1. Because pushing money to wallets can be exploited and thus is a security concern
  2. Many people might mess up and lose money or just not withdraw because they fear they might mess up
  3. When people don’t withdraw their money the problem is what to do, either give to charity, keep them or push them to a predefined wallet
2 Likes
#204

  1. It 's better for the user to pull their funds because then the contract will never run out of gas (as the burden is then placed on the user). Also, this breaks up the code into smaller, simpler functions, allowing for more robust security checks.

  2. The writer’s one concern with users pulling funds is that is puts more of a responsibility on them. This can lead to errors especially when users are new dapps.

  3. He didn’t know whether to give the funds back to random participants or to charity;

2 Likes
#205

1.There are two main reasons:
*Having such a large code can make the function run out of gas, and we dont want that at all.
*Sending Ether to unknown addresses increases the risks of being attacked.
2. User error, some of them were too lazy to withdraw it and others didnt understand how it worked.
3.Lazy people.

2 Likes
#206

  1. Why shouldn’t you just send people their ether directly (push)?
    It could run out of gas and could lead to security vulnerabilities.

  2. What’s the writers argument against the “pull” design?
    Users should not have to interact with smart contracts more than they absolutely need. People who are unfamiliar with technology often make mistakes when using them.

  3. What problem did the writer find with people not withdrawing their money?
    Finding good ways to satisfy different user demands (e.g., withdrawing by themselves, asking admins to send the payout back with a fee, or giving the money to a good cause) without compromising security.

1 Like
#207

For two reasons: the run of gas and security vulnerabilities for unknown addresses. Also other organizations refers that the receiving address could implement a fallback function that could throw an error.

It’s a good design for people who has knowledge with smart contracts but not for people who are not familiarize. They would make mistakes.

He didn’t know what to do with the money.

1 Like
#208

1 - we could be calling contracts with malicious code and it might be really expensive if there are many users to send to.
2 - It presents the users with a poor UI, as they now need to perform more transactions
3 - Lots of people just didn’t withdraw. The question was then whether keep the money, donate it or give it to the people that did withdraw.

2 Likes
#209
  1. You do not want to send people either directly via a push approach because you could run out of gas.
  2. The writer argument against the pull design is that users should not have to interact with contracts more than absolutely necessary.
  3. The writer found the problem of what to do with users funds that were left behind. Do you donate them to a charity, keep it yourself, or spread it to other predesignated participants.
1 Like
#210

  1. Why shouldn’t you just send people their ether directly (push)?
    Because you could potentially run out of gas and/or sending ether to unknown addresses could lead to security vulnerabilities.

  2. What’s the writers argument against the “pull” design?
    To interact with smart contracts only when absolutely necessary as mistakes could prove very costly.

  3. What problem did the writer find with people not withdrawing their money?
    To either donate the funds to charity or to send it to a pre-defined address.

1 Like
#211
  1. Why shouldn’t you just send people their ether directly (push)?
    It could run out of gas and could lead to security vulnerabilities.
  2. What’s the writers argument against the “pull” design?
    Users should not have to interact with smart contracts more than they absolutely need. People who are unfamiliar with technology often make mistakes when using them.
  3. What problem did the writer find with people not withdrawing their money?
    Finding good ways to satisfy different user demands (e.g., withdrawing by themselves, asking admins to send the payout back with a fee, or giving the money to a good cause) without compromising security.
1 Like
#212
  1. Why shouldn’t you just send people their ether directly (push)?

Sending people their ether directly could run out of gas and sending ether to unknown addresses as the writer said, could cause security vulnerabilities.

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

The writer’s argument against the pull design is that external calls can fail either accidentally or deliberately and create vulnerability issues in the “pull” design.

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

The writer found that people do not want to interact with smart contracts unless they absolutely have to, since they are concerned about making mistakes, especially if they are new to smart contracts.

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

people won’t potential run out of gas by executing the transfer function too often.

  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.
  2. What problem did the writer find with people not withdrawing their money?
  1. Sending ether back to all the participants could run out of gas.
  2. Sending ether to unknown addresses could lead to security vulnerabilities.
#214

  1. You shouldn’t just send people their ether directly (push) because it can lead to two main problems: (a) Sending ether back to all participants could run out of gas, causing the transaction to fail, and (b) sending ether to unknown addresses could lead to security vulnerabilities. Using the “Pull over Push” pattern helps mitigate these issues by having users initiate the withdrawal themselves.

  2. The writer’s argument against the “pull” design is that it requires users to interact with the smart contract more than they need to, and this can lead to mistakes, especially for people new to smart contracts.

  3. The problem the writer found with people not withdrawing their money is that it leads to unclaimed funds in the smart contract. After a week, the contract owner can clear these funds using the clear() function, but this may not align with the users’ preferences or the intended message of the BlockParty Dapp.

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

That means the addresses which will be paid, let’s assume, which been registered to the contract as a participant can be a malicious smart contract instead of a real person’s wallet and transfering funds in multiple creditors might cause gas-consuming issues as well, like txns halt and reverts each time.

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

If you combine all their payments into one transaction and there’s an issue, like a mistake in the code or someone would try to cheat, it will affect everyone’s payments. Instead of giving money to everyone all at once and risking something going wrong, it’s better to let each person withdraw (pull) their own money.

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

Sending ether back to all the participants could run out of gas and sending ether to unknown addresses could lead to security vulnerabilities.

They changed payback to simply mark who entitles the payout and introduced withdraw() function which allows participants to take the payout, means that, instead of automatically pushing funds to participants, they modified their algorithm to keep track of who is eligible to receive the payout.

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

Could run out of gas. And sending ether to unknown addresses could lead to security vulnerabilities. Every ether transfer implies potential code execution. The receiving address can Implement a fallback function that can throw an error. We can we should never trust that a send call Will execute without error. Contracts should favor pull over push for payments.

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

Users should not need to interact with smart contracts 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?

Some people did not withdraw their money for 7 Days up to 281 days. The smart contract has a function called clear () which allows contract owner to take all the leftover and default cooling. Is set to 1 week. People are lazy and don’t withdraw but want their money but have different ideas of what they want done with it. for example refund with additional fee, withdraw, or go to charity.

#217
  1. You risk interacting with a malicious contract and it could use up all your gas.
  2. Users could make mistakes while pulling especially if inexperienced
  3. Some people didn’t withdraw