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
Related
Background on the compromised address
I fell for a MEW phishing scam, and I use that particular eth address for airdrops, investments sites etc, I'm expecting eth to be paid to me through that address, and I can't change the address because I've already used it.
My approach
My intended approach is: a script that will perpetually check my address for any incoming ether, and automatically transfer it to another address. This needs to happen before the scammer transfers the ether out. I am willing to use a high gas price, so the transfer can be swiftly included in a block.
How to Implement?
From my little research, I've found out that this can only happen through webjs, and having the full eth node. Can I use infura and Nodejs to do this? If it's possible, how do I do it?
Racing the Scammer
You are unlikely to be able to out-compete the scammer in a race to withdraw. They are "professionals" at this, and can probably submit the withdrawal transactions faster than you.
Stop the Bleeding
Your best option is to find a way to change the location of any future dividends & withdrawals. For example, if you have an ERC20 token that sends you dividends (and the scammer didn't already drain the token from your account), then transfer that token to an uncompromised account. Dividends will start appearing in your new account, and the scammer cannot intercept them.
Prevention
I'm sorry for your loss. Many people have learned expensive lessons this way. It's worth reading up on prevention techniques to avoid phishing scams, to help protect yourself in the future.
We are thinking of building a dapp for finding salon near me and allowing booking. In such application end users has to be shown the salons which are at a certain distance from their current location. Where would be query that data from. Cause I don't think so that kind of querying is possible in solidity. Do we need to bring in any RDBMS in such a scenario to store salon data so that we can query it easily and booking information can be sent to blockchain.
Is hybrid application the only way out? People are talking about IPFS should be used for storing the images, videos and other data. Is that the solution, if yes then how would we query it from there? Moreover, would it be fast enough?
TL;DR: Short answer: you might, but you shouldn't.
The real question here is what do you need ethereum for in this project?
In Ethereum, each write operation is costly whereas reading data isn't. Write operations are transactions, read are calls.
It means that "uploading" your salon list will cost you money (i.e. gas), but also each data update (opening hours, booking ..).
For the mysql specific part of your question, well Ethereum is not designed for that kind of operation.
Something with an oracle might do the trick but it's truly not designed for. See Ethereum like a way to intermediate transactions between peers that stores every transaction publicly and permanently.
According to the Wikipedia page blockchains are basically a "continuously growing list of records". Ethereum has the possibility to make workers run some code in exchange of gas.
This code (or Smart Contract) only purpose "to facilitate, verify, or enforce the negotiation or performance of a contract" (here contract is a legally binding contract).
From what you described, IMO a simple web application with "standard" SQL is more than enough.
You just have to store the salons' GPS coordinates and do the closest match(es) from the user's GPS coordinates.
You likely want to separate your application into two parts:
- The part which shows the available booking times
- The part which makes a new booking
I am writing a test application that allows people to purchase tokens.
I am adapting the example from here: https://ethereum.org/token#the-code
Here are my questions:
What is the best way to have a registry of purchases? I would assume this can be a simple web interface that queries the block chain to see who has bought what.
If this is correct, does this mean running geth on a server in order to have the latest blockchain available and then using some kind of PHP / Javascript library in order to query the blockchain every so often?
What is the best way to sell tokens? Could this be done via a web interface or would it be best to sell via the ethereum wallet? Or both?
Lets say I want to split a token into a number of parts as such:
A: A full token = 1
B: 1/10th of a full token called a 10token
C: 1/10th of a 10token called a 100token
D: 1/10th of a 100token called a 1000token
What is the best way to represent this?
For instance, if someone owns a full token they have 100% of that tokens rights. However it would be possible for many parts of a token to be owned by different people who will share rights according to their share.
Visually, it would look something like this:
How to do this is a puzzle to me.
What is the best way to have a registry of purchases? I would assume this can be a simple web interface that queries the block chain to see who has bought what.
You can do the registry in your token sale smart-contract by making event like this
event TokenPurchase(address indexed purchaser, address indexed beneficiary, uint256 value, uint256 amount);
In this case you will be able to watch event log later and get all the addresses you need.
Another approach is to add a simple map to your contract like this mapping (address => uint256) public deposited; and add elements to this map on purchases.
About the representation of the registry for the users you better just take a look at ICO's you like and make it in the same way.
What is the best way to sell tokens? Could this be done via a web interface or would it be best to sell via the ethereum wallet? Or both?
I would say both. But it depends on who are your tokens for. If you sell only using ethereum wallet you will loose a lot of users not familiar with blockchain.
Lets say I want to split a token into a number of parts as such
Take a look at the solutions offered by OpenZeppelin project. Just read their contracts code and I think you'll find solutions you were looking for in this post.
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.
A little background: I have the opportunity to present the idea of a public API to the management of a large car sharing company in my country. Currently, the only options to book a car are a very slow web interface and a hard to reach call center. So I'm excited of the possiblity of writing my own search interface, integrating this functionality into other products and applications etc.
The problem: Due to the special nature of this company, I'll first have to get my proposal trough a comission, which is entirely made up of non-technical and rather conservative people. How do I explain the concept of an API to such an audience?
Don't explain technical details like an API. State the business problem and your solution to the business problem - and how it would impact their bottom line.
For years, sales people have based pitches on two things: Features and Benefit. Each feature should have an associated benefit (to somebody, and preferably everybody). In this case, you're apparently planning to break what's basically a monolithic application into (at least) two pieces: a front end and a back end. The obvious benefits are that 1) each works independently, so development of each is easier. 2) different people can develop the different pieces, 3) it's easier to increase capacity by simply buying more hardware.
Though you haven't said it explicitly, I'd guess one intent is to publicly document the API. This allows outside developers to take over (at least some) development of the front-end code (often for free, no less) while you retain control over the parts that are crucial to your business process. You can more easily [allow others to] add new front-end code to address new market segments while retaining security/certainty that the underlying business process won't be disturbed in the process.
HardCode's answer is correct in that you should really should concentrate on the business issues and benefits.
However, if you really feel you need to explain something you could use the medical receptionist analogue.
A medical practice has it's own patient database and appointment scheduling system used by it's admin and medical staff. This might be pretty complex internally.
However when you want to book an appointment as a patient you talk to the receptionist with a simple set of commands - 'I want an appointment', 'I want to see doctor X', 'I feel sick' and they interface to their systems based on your medical history, the symptoms presented and resource availability to give you an appointment - '4:30pm tomorrow' - in simple language.
So, roughly speaking using the receptionist is analogous to an exterior program using an API. It allows you to interact with a complex system to get the information you need without having to deal with the internal complexities.
They'll be able to understand the benefit of having a mobile phone app that can interact with the booking system, and an API is a necessary component of that. The second benefit of the API being public is that you won't necessarily have to write that app, someone else will be able to (whether or not they actually do is another question, of course).
You should explain which use cases will be improved by your project proposal. An what benefits they can expect, like customer satisfaction.