does anyone know how to restrict a function to only being callable by externally owned accounts? My contract would likely be vulnerable to a contract mass creating contracts and then flashloaning / calling the contract a bunch of times in one tx. This is because there are some cooldown mechanics in the game that would be circumvented by a multi-account user.
I know I can use tx.origin == msg.sender but tx.origin is supposed to be on the deprecation path. Are there alternatives?
Sep 1, 2023, 9:56 PM
function isContract(address _addr) private returns (bool isContract){
uint32 size;
assembly {
size := extcodesize(_addr)
}
return (size > 0);
}
uint32 size;
assembly {
size := extcodesize(_addr)
}
return (size > 0);
}
Try this
Sep 1, 2023, 9:57 PM
thanks I'll give that a try. I assume that checks if there's code attached to an address. I hope it doesn't break my foundry tests tho lol
Sep 1, 2023, 9:58 PM
That's bypassable in the constructor tho
If you do actions in your constructor and call another contract, msg.sender.data is 0 but you're executing code
Sep 1, 2023, 10:04 PM
Yeah I saw that on the stack discussion https://ethereum.stackexchange.com/questions/15641/how-does-a-contract-find-out-if-another-address-is-a-contract
I assume in the constructor you could call some function that would send funds to you via the flashloan, then you could call my contract to exploit. So that seems like the vulnerability applies
I assume in the constructor you could call some function that would send funds to you via the flashloan, then you could call my contract to exploit. So that seems like the vulnerability applies
I wonder if its possible somehow to set a nonce inside my contract that could be incremented in such a way that I would see if it is adjusted more than once within one larger transaction
Sep 1, 2023, 10:07 PM
Is there a better way?
Sep 1, 2023, 10:10 PM
as far as i know, tx.origin == msg.sender is the best way.
I still don't know why they want to discontinue tx.origin
It's dangerous but useful sometimes
By EVM design, you don't wanna do block contracts but instead work on your logics to let them interact anyway
I still don't know why they want to discontinue tx.origin
It's dangerous but useful sometimes
By EVM design, you don't wanna do block contracts but instead work on your logics to let them interact anyway
Sep 1, 2023, 10:11 PM
tx.origin won't be discontinued anytime soon, it's a major breaking change that will cripple many contracts
Sep 1, 2023, 10:13 PM
i truly hope so.
But they already removed the gas refund from selfdestruct 🤷♂️
But they already removed the gas refund from selfdestruct 🤷♂️
Sep 1, 2023, 10:14 PM
at least for me, the game is an economic/game theory game. The concept of flashloans pretty much wrecks it though lol, but I defeated that with a stepwise increasing cooldown. But if you distribute the flashloan across multiple accounts then the cooldown is defeated as well.
Sep 1, 2023, 10:14 PM
seems you have a similar problem like "how do i avoid snipers on my token"
Sep 1, 2023, 10:15 PM
yeah it is definitely similar. my game works with bonding curves so you could look at it like any dex/mint
Sep 1, 2023, 10:16 PM
gas refund is a minor change as it looks like, many contracts rely on tx.origin
vitalik and few other dictators won't get to decide everything
vitalik and few other dictators won't get to decide everything
Sep 1, 2023, 10:16 PM
99/99 tax 👺
Sep 1, 2023, 10:16 PM
yolo ima use tx.origin then. If project is still relevant when they deprecate tx.origin, hopefully they will at least tell people alternatives at that time
but tx.origin broke all the foundry tests cuz of vm.prank ... 😭😭😭😭😭😭
sigh..
ah nvm, prank has a version you can also set tx origin 😅😅
Sep 1, 2023, 10:51 PM
tx.origin isn't supposed to work accordingly with vm.prank and that's the whole point of the vm.prank (to impersonate others)
Sep 2, 2023, 5:13 AM