I am thinking of investing in a new erc-20 token that looks good but it seems that the developers are connected with some fraudulent coins. The Dev says that scammers are creating smart contracts and transferring ownership of the fraudulent contract to the original developer's contract to steal money from buyers. So my question is, is it possible to transfer ownership from one contract to another without signing the transaction? And if yes, how can scammers transfer funds? I think only the owner can transact. Thanks!
I googled but couldn't find an answer
is it possible to transfer ownership from one contract to another without signing the transaction?
Only a transaction can store state changes - for example value of a variable hold an authorized address.
So while it is possible to transfer contract ownership, it is not possible to do so without a transaction.
What's the standard way to cover the costs for a Chainlink oracle?
Let's say that I have an NFT mint function that requires the use of external data, or of an external VRF. It costs, say, a fee of 1 LINK. What's the best practice to make the user cover for that cost? (ideally, the best one from both a UX standpoint and a decentralization one)
I see 4 scenarios, all with serious drawbacks:
embedding into the mint function a transfer of amount of LINKs, something like this: require(linkContract.transferFrom(msg.sender, this, amount));. Two issues with this, though: a. you need the user to pre-approve the transfer (linkContract.approve(myContract, amount);), adding one step to the funnel; b. users need to actually have enough LINK in their wallet, which is even more difficult to explain to non-advanced users and makes the funnel even longer
slightly improving from previous point, use ERC677 transferAndCall function: the user calls it on the LINK contract itself, which in turn triggers the mint function by calling onTokenTransfer. Issue: same as previous point, the user needs to have LINK in their wallet - not exactly the best UX
embedding into the contract a logic such that the contract itself figures out on the fly the equivalent of the LINK fee in ETH (using Chainlink's price feeds). The, it "just" require(msg.value == feeEquivalentInEth); - this way, the user only interacts in ETH, and the whole LINK thing would be handled automagically behind the scenes. Issue: need to constantly swap ETH with LINKs, which can lead to either price slippage or(/and) gas costs going ballistic
slightly different from previous point, but still same idea: use LINK meta transaction, where you act as a relay on behalf of the user, cover the costs, and send back an invoice — explained here. Issue: the relay needs to cover for the costs first, and then demand payment back, which is the opposite of a trustless scenario. One could mitigate this by asking for payment first, but gas costs cannot be forecasted easily so not really a solution either.
What's the industry standard? It seems to me highly unlikely that nobody figured this out already, and I'd hate to re-invent the wheel
I need some assistance. I am working on a smart contract that will allow a user to save a string (mapping(address=>string)). The only problem, I would like the contract to pay for the gas for the user to save the string. Any idea on how to
This is a proposed feature but not yet implemented: https://github.com/ethereum/EIPs/issues/1776
This feature is known as meta-transaction: the sender of the transaction doesn't pay for gas.
While there is no native way to conduct meta-transactions yet, there are third-party efforts to implement it, searching the web with meta-transaction keyword should yield useful stuff.
Have a look at the Gas Station Network Alliance:
https://blog.zeppelinos.org/gas-station-network-alliance/
Depending on your use case, if you don't need to save strings directly on chain, an alternative would be something like Peepeth - microblogging with a soul. Peepeth batches signed messages stored in IPFS and anchors the batched data on chain: https://peepeth.com/a/free
I'm a product manager not a Blockchain coder, looking for a 2nd opinion and some general good practice advice. I have one question in bold, the rest is background.
Background:
We have an app in development that will write user's information into a Smart Contract on the ETH blockchain.
The SC's we deploy contain information only, no Ether.
Each user has their own SC which stores only that users specific information.
Our App allows the user to edit and update this information and then upload the changes, encrypted, into their own SC.
The user's SC address is 'tied' (sorry for lack of correct terminology) to their own Ether wallet.
I see on Etherscan (Ropsten) there is a Contract Creator address which is a constant for all the SC's our App creates.
I'm assuming that the contract creator address is unique to us, it is code we've created and as such it deploys only our Smart Contracts on behalf of our Application.
I was hoping that each SC address would be known only to its owner and us only. Now I see that anyone can access this information.
My Concerns:
Should there be an exploitable flaw in our code then a bad actor has a list of contract addresses to attack.
The worst-case risk to us is that a bad-actor could access each users data in an unencrypted state if a flaw exists in our publicly accessible code.
The Bad-Actor then uses that flaw and the list of smart contract addresses they can get from Etherscan to download multiple users data.
My Question
Are these realistic concerns?
If so what general directions can we look at to mitigate these risks
If so is there a way I can obscure the Creator address in Etherscan without other negative consequences
The developers are outsourced 3rd parties and excellent people to work with. But Im looking for an alternate opinion than just theirs at this time as a double check.
Apologies if the information Ive provided is confusing or incomplete.
Thanks in advance for your time.
I was hoping that each SC address would be known only to its owner and us only. Now I see that anyone can access this information.
As you have addressed here, data regarding the blockchain (i.e. transaction hashes, contract addresses, and user addresses) is transparently available. This is by-design with Ethereum and allows for the traceability aspect of the ledger.
Furthermore, smart contract data is potentially available to any actor in the Ethereum network. However, that is based upon the following:
In order to access the smart contract data, an actor would require the contract ABI. This interface allows code to be written to interact with the smart contract methods. Now, it is helpful to understand that this ABI could hypothetically be easily reverse-generated with enough details of how your DApp interacts with the existing smart contract.
If your smart contract logic has exploitable flaws, a malicious actor on the network could take advantage of this. This is why contracts should be well-written and unit tested with near (if not) 100% code coverage. You should also identify the potential actors in each contract scenario and be sure your test cases appropriately cover these scenarios.
If so what general directions can we look at to mitigate these risks
Given the contract scenario you have described, if the only actor who should have access to these user data smart contracts is the user them self, then you simply need to apply something akin to a function modifier to your smart contract logic. In the linked example, access to the smart contract data is restricted to a single specific Ethereum user address.
If so is there a way I can obscure the Creator address in Etherscan without other negative consequences
Sure. It sounds like you're currently using a single account to deploy the smart contracts, hence the creator address is constant. (Side note: I'm not sure why you're deploying the contract on behalf of the user with this account, it sounds like the user should be deploying their own smart contract). Regardless, you could simply create a new proxy user address each time you deploy the smart contract. However, I don't see any benefit to doing so and this would just be an example of security through obscurity.
We have a service where we literally give away free money.
Naturally said service is ripe for abuse. To defend against this we do the following:
log ip address
use unique email addresses (only 1 acct/email addy)
collect more info like st. address, phone number, etc.
use signup captcha
BHOs (I've seen poker rooms use these)
Now, let's get real here -- NONE of this will stop a determined user.
Obviously ip addresses can be changed via a proxy (which could be blacklisted via akismet) but change anyways if the user has a dynamic ip or if more than one user is behind a NAT'd network (can we say almost everyone?)
I can sign up for thousands of unique email addresses each hour -- this is no defense.
I can put in fake information taken from lists for street addresses and phone numbers.
I can buy captchas from captcha solving services (1k for $5).
bhos seem only effective for downloadable software -- this is a website
What are some other ways to prevent multiple users from abusing the service? How do all the PPC people control click fraud?
I know we could actually call the person but I don't think we are trying to do that anytime soon.
Thanks,
It's pretty difficult to generate lots of fake phone numbers that can send and receive SMS messages. SMS verification could go a long way towards cutting down on fraud. Of course, it also limits you to giving away free money to cell phone owners.
I think only way is to bind your users accounts to 'real world' information, like his/her passport number, for instance. Of course, you'll need to make sure that information is securely stored and to find some way to validate it.
Re: signing up for new email accounts...
A user doesn't even need to do that. Please feel free to send your mail to brian_s#mailinator.com, or feydr.asks.a.question#spamherelots.com, or stackoverflow#safetymail.info, or my_arbitrary_username#zippymail.info. I haven't registered any of those email addresses, but all of them will work.
Those domains are owned by ManyBrain, and they (and probably others as well) set the domain to accept any email user. ManyBrain in particular then makes the inboxes for those emails publicly accessible without any registration (stripping everything by text from the email and deleting old mail). Check it out: admin#mailinator.com's email inbox!
Others have mentioned ways to try and keep user identities unique. This is just one more reason to not trust email addresses.
First, I suppose (hope) that you don't literally give away free money but rather give it to use your service or something like that.
That matters as there is a big difference between users trying to just get free money from you they can spend on buying expensive cars vs only spending on your service which would be much more limited.
Obviously many more user will try to fool the system in the former than in the latter case.
Why it matters? Because it is all about the balance between your control vs your user annoyance. I see many answers concentrating on the control part, so let's go through annoyance, shall we?
Log IP address. What if I am the next guy on the computer in say internet shop and the guy before me already used that IP? The other guy left your hot page that I now see but I am screwed because the IP is blocked. Yes, I can go to another computer but it is annoyance and I may have other things to do.
Collecting physical Adresses. For what??? Are you going to visit me? Or start sending me spam letters? Let me guess, more often than not you get addresses with misprints at best and fake ones at worst. In fact, it is much less hassle for me to give you fake address and not dealing with whatever possible spam letters I'll have to recycle in environment-friendly way. :)
Collecting phone numbers. Again, why shall I trust your site? This is the real story. I gave my phone nr to obscure site, then later I started receiving occasional messages full of nonsense like "hit the fly". That I simply deleted. Only later and by accident to discover that I was actually charged 2 euros to receive each of those messages!!! Do I want to get those hassles? Obviously not! So no, buddy, sorry to disappoint but I will not give your site my phone number unless your company is called Facebook or Google. :)
Use signup captcha. I love that :). So what are we trying to achieve here? Will the user who is determined to abuse your service, have problems to type in a couple of captchas? I doubt it. But what about the "good user"? Are you aware how annoying captchas are for many users??? What about users with impaired vision? But even without it, most captchas are so bad that they make you feel like you have impaired vision! The best advice I can give - if you care about user experience, avoid captchas as plague! If you have any doubts, do your online research first!
See here more discussion about control vs annoyance and here some more thoughts about being user-friendly.
You have to bind their information to something that is 'real world', as Rubens says. Of course, you also need to be able to verify this information (I can just make up passport numbers all day if you don't check to make sure they're correct).
How do you deliver the money? Perhaps you can index this off the paypal account, mailing address, or whatever you're sending the money to?
Sometimes the only way to prevent people abusing a system is to not have the system in the first place.
If you're doing what you say you're doing, "giving away money to people", then surprise surprise, there will be tons of people with more time available to try to find ways to game the system than you will have to fix it.
I guess it will never be possible to have an identification system which identifies fake identities that is:
cheap to run (I think it's called "operational cost"?)
cheap to implement (ideally one time cost - how do you call that?)
has no Type-I/Type-II errors
is scalable
But I think you could prevent users from having too many (to say a quite random number: more than 50) accounts.
You might combine the following approaches:
IP address: can be bypassed with VPN
CAPTCHA: can be bypassed with human farms (see this article, for example - although they claim that their test can't be that easily passed to other humans, I doubt this is true)
Ability-based identification: can be faked when you know what is stored and how exactly the identification works by randomly (but with a given distribution) acting (example: brainauth.com)
Real-world interaction: Although this might be the best one, but I guess it is expensive and not many users will accept it. Also, for some users/countries it might not be possible. (example: Postident in Germany, where the Post wants to see your identity card. I guess this can only be faced in massive scale by the government.)
Other sites/resources: This basically transforms the problem for other sites. You can use services, where it is not allowed/uncommon/expensive to have much more than 1 account
Email
Phone number: e.g. by using SMS, see Multi-factor authentication
Bank account: PayPal; transfer not much money or ask them to transfer a random (small) amount to you (which you will send back).
Social based
When you take the social graph (vertices are people, edges are connections), you will expect some distribution. You know that you are a single human and you know some other people. So you have a "network of trust" (in quotes, because I think this might be used in other context as well). Now you might not trust people / networks how interact heavily with your service, but are either isolated (no connection) or who connect a large group with another large group ("articulation points"). You also might not trust fast growing, heavily interacting new, isolated graphs.
When a user provides content that is liked by many other users (who you trust), this might be an indicator that there is a real human creating it.
We had a similar issue recently on our website, it is really a hassle to solve this issue if you are providing a business over one time or monthly recurring free credits system.
We are using a fraud detection solution https://fraudradar.io for a while and that helped us a lot to clean out most of the spam activities. It is pretty customizable with:
IP checks
Email domain validity
Regex rules
Whitelisting options per IP, email domain etc.
Simple API to communicate through
I would suggest to check that out.