/biz/ - Business & Finance

only applies to data that can be extracted from one source. There still plenty of applications with multiple source API.

For a lot of data, there are multiple sources.

>>8310468
Smart contracts of high value will need data from centralized sources. If we want link to hit 1000 at some point in the next 2-3 years then it needs to be handling high value contracts ie: derivatives, insurance etc. which get their data from centralized sources

>>8310522
Oh ok

>>8310452
Even when there is only one API source, you are still reducing the possible points of failures by 1, which is an improvement. Therefore chainlink is still very useful.

That's of course true.
When the data source is a docusign document that I sign then my signature is not decentralised. I need to decentralise myself in order to make this happen.
Two options: Sergey missed this obvious and fatal flaw. Or OP is a fucking brainlet
You decide

>>8310452
>thinks in 2 minutes and a 10sec write-up he has thought this through better than someone who actually has been working on this project for literally multiple years
>probably can't be serious and therefore can be regarded as a 5d chess shill.

Either really retarded FUD or somewhat good shilling, depending on initial motivation.

>>8310452
OP's fatal flaw

The reason OP ultimately sucks dicks is because he didn't read any of the stuff that talks about this in the whitepaper and thinks he knows better than the guys that spent years working on it.

>>8310542
But the point of decentralization is to increase the attack surface to the point where it’s economically unfeasible to attack. It’s all about creating security through enough decentralization. Doing it by 1 isn’t enough

>>8310605
>>8310682

Deluded brainlets unable to come up with good counter arguments. Pay attention nu /biz/ these are the reactions of cult members unable to think for themselves. Muhhh Sergey muhh philosophy major

>>8310760
Ah, you are indeed good OP! Baiting zealous LINK marines into debunking your half-assed FUD in order to shill this even more. But you are making it too easy, the bait has to be better at this stage because nobody really cares anymore to convince any retards to buy LINK. Actually most people just want everybody else who doesn't own LINK at this point to miss out. I also do. Please don't buy, sir.

>>8310760
Imagine being as stupid as yourself.

>>8310810
This

capgemini also expects iot devices to exponentially grow in the coming years, i guess that's where you can get data from. so chainlink would be viable for a majority of cases. you literally said that since it doesn't apply to one specific niche then the token is useless overall

>>8310760
Yeah man they're gonna use only 1 source API and not multiple API to come to a consensus.

This is what I was thinking too.

But as mentioned here before LINK removes one more additional point of failure for smart contracts using real data

So we're going from:
Trusted data source --> trusted oracle --> trustless contract

To:
Trusted data source --> trustless oracle (Link) --> trustless contract

Big brain niggas like Ari Paul think this is an important step, so that's why I believe in it atm

>>8310522
And that's fine. Multiple nodes will have multiple API sources. Multiple API sources = decentralized data aggregation.

>>8310522
all data comes from centralized sources. this is precisely why an oracle is needed.

i think these type of questions boils down to being unable to imagine the potential use cases of smart contracts in general. fudders especially tend to cling to those where it wouldn't necessarily be useful. it doesn't have to be used in literally every single thing. this anon made a great point, >>8310548 i guess since he cannot decentralize himself then it is useless. you are bordering philosophical (specifically ontology) with your arguments. luckily sergey is a philosophy major lmao

>>8310810
Just lol at your 5d meta chess shit. Debate the fact that if you follow the chain of data in a smart contract powered by an oracle service line link the ultimate source of that data is still centralized. Therefore you don’t have a secure end to end setup. Pro tip: you can’t

>>8310522
>If we want link to hit 1000 at some point in the next 2-3 years
>2-3 years
LINK $1000 EOY

>>8310914
OF FUCKING COURSE IT IS A BIG STEP.

God, are most of you really as stupid as you seem? I thought most of the people just meme being full time retards, but I am beginning to doubt my assumption.

>>8310954
Lol you're literally retarded. You got beat in 5 minutes.

>>8310957
You still have the trusted data source problem

>>8310954
No, no. You will not bait anybody here. Stay away and please don't buy. Not meming here. Do. Not. Buy.

>>8310892
that's a great point to this that tends to get ignored. instead of simply attacking one node they'd need to compromise the whole network. that's one less attack vector for malicious actors. if the important data comes from a centralized source and since it is supposed to be highly sensitive data, we can assume that the source is involved in the smart contract. malicious actors in this scenario would be tampering with the data. if it was so fucking important then the source shouldve secured it then. it is irrelevant to chainlink's decentralized oracle and smart contracts in general

>>8310983
I can't wait to put my huge LINK gains into the decentralized data source and 1000000000000x my money.

>>8310452
Another example of how Chainlink can't be fudded. You are wrong. The more serious contracts can require more than one data source.

>>8310954
>>8310914
if their data fails they know who to blame, but with LINK oyu don't need to trust the delivery of the data and the execution of the Smart Contract (assuming there's only 1 source for this data)

and if there's more than 1 source for the data (and there's plenty of useful data with multiple sources) then it's the perfect network to create smart contracts

sage'd

>>8310914

This. OP thinks it’s worthless to have a trustless middleman between trusted data and trustless smart contracts. In most cases, a trusted oracle is more vulnerable than a trusted data source. Look at all the times oraclize has been down, causing hell for all the dApps using its service and tell me how Chainlink isn’t taking the weakest link out of that equation.

>>8310983
luckily there are lots of cases where there can be multiple data sources for one event if you still want to cling to that "problem". for cases where there is a trusted data source it would have been a problem in legacy systems in case someone tampered with the data from the source. chainlink's possible use case in this scenario, besides reducing the attack vector, would be to increase efficiency in the process.

>>8310983
>You still have the trusted data source problem
no you dont. all data sources are untrusted and centralized. the oracle is a system where you statistically do away with the most egregiously untrutsable sources of data.

do you even know what LINK is, bro?

>>8310892
Re-read the thread brainlet. For certain data that doesn’t have multiple sources decentralization is not a solution to security. If I’m getting patient data from an insurance company that comes from 1 source and poses the danger of an automated smart contract delivering value on the basis of a centralized source of input data

>>8310955
Checked nigga

>>8311013
The 2 parties i nthe contract would most likely provide the data source to be used, if one of the parties fuck with the data source you know who to blame in the interaction. They get sued for breach of contract.

>>8310452
Weak FUD. The oracle's purpose is to securely transmit data in a temperproof way whether it's a one-to-one, one-to-many, many-to-one, or many-to-many relationship. Depending on the setup's structure, the overall level of centralization can vary greatly. It's not a black and white thing, but a spectrum where the most likely use cases will fall somewhere in the middle, skewing somewhat to the decentralization side

>>8310528
>has nothing intelligent to contribute yet still feels compelled to say something
>strong sign of brainlet
just stfu

the IQ of a typical LINK fudder is just so low. sad.

>>8310983
So solve it nigga. Also this>>8311021

>>8311066
OP used an example where there is highly sensitive data that would only come from that party. in that case, chainlink/smart contracts or not they still wouldve been fucked up. at least with decentralized oracles the attack vector would be reduced. i dont know if what you said is true though, that trusted oracles are more vulnerable than trusted data source. regardless it doesn't make sense to not trust the data source especially if it can only come from one source. how the fuck would you verify it then. best example to this fud is this in case this stupidity comes up again >>8310548 decentralized yourself, motherfucker

>>8311092
and if the insurance company produces false data then you have the easiest open and shut breach of contract case ever.

Okay anons, there's only a couple fud points holding me back from buying in. First, I've heard a couple times that Chain LINK is using Intel (the company) as part of its tech, and apparently this aspect of Intel is not too secure. Also, is it really feasible for companies to build and use their own Oracle's? Tried reading the wp but I'm a brainlet so didn't understand a lot of it

>>8311092
delivery of data is an attack vector if you are so concerned with security. regardless there are other use cases that doesn't rely on a single data source
>>8311110
yes it would be much easier to pinpoint the problem in the scenario OP pointed out

>>8310760
There are no arguments for your stupidity, you are unable to understand what is ChainLink's job and what isn't.
ChainLink cannot magically protect the source itself because they do not own that data, what it actually does is it safely inputs the data into the blockchain. I know it's hard for you to understand what this means but this is the main feat like >>8311113 explains in this post.

Sergey wouldn't be working with SWIFT and focusing on other high value contracts like derivatives and insurance if he didn't have a solution for it.
They mention this in the whitepaper and will probably require some work from future users to get ChainLink safely implemented in as much decentralized manner as possible; something like distributing sources.

Also you make a lot of assumptions about some thing that you probably have no idea about.
Do you work in the financial IT sector, do you know how they handle their data?

>>8310522
If the centralized source fucks you over with falsified data, you can just sue, because thanks to Chainlink you know that it wasn't tampered with afterwards.

>>8311173
don't buy chainlink.
>>8311172
also i forgot to point this out, thank you for elaborating my previous argument. since the data comes from a single source that source would be held liable from any stupid shit that OP wants to happen. irrelevant to chainlink's purpose

>>8311184
I don’t think you truly understand the context of business and contracts. All link does is decentralize the method of data delivery to smart contracts and blockchains. If your data source however comes from a single source that is again a critical point of failure. You like to think you’re smart but you fucking aren’t. Don’t you ever even try to attempt to sound smart again you degenerate brainlet

>>8311173
>>8311211
Sirrss.. please buy my bags!

>>8311238
>i am just pretending to be retarded
thank you for the subtle shill anon, it at least makes us think about any flaws in the project. if you are being serious do you mind answering how you cant just sue if that single source fucks up their security?

>>8311238
you do realize that they can decentralize the way they store the data if they really worry about being hacked, right?

ChainLink dosen't solve EVERYTHING, it just solves the oracle problem which is a huge step for DLT and SCs itself

>>8311238
I'm a lawyer. If you think quickly and efficiently figuring out that a point in a contract was altered is useless than you can't be saved.

>>8310522
there are high value smart contracts for both cases. Your mentioned application examples could have multiple API sources. The link platform will work is that it is not visible which nodes supply data to the contract, so it will be unclear which node to attack

>>8311283
you don't even have to go that far. it's irrelevant to chainlink. btw im glad that this has been discussed thoroughly, i think in all link threads this has been the first time the "single trusted source" fud has been critiqued hard. thanks for this post OP

>>8311238
Kek, try to be less butthurt faggot.

Listen here brainlet, you have no idea what you're talking about, you don't understand the role ChainLink plays in the ecosystem.
Your point has been refuted more than 10 times in this thread and yet you still continue to post the same autistic shit over and over again.

Try doing some more research, ok pal? There's no reason to get upset right away, you'll get it eventually. We've all been there.

>>8311334
It's a pretty easy one to destroy. In high value contracts the parties who interacting would supply the API to the contract. If data was altered to the trusted data source you would have irrefutable proof that the data was altered and the contract wasn't executed as agreed. The party whose data was alterred in their favor would be liable for not securing the data.

If they use a 3rd party for the data source they would likely have an agreement to supply accurate data to the contract.

Party 1 who got fucked sues > Party 2 for breach

Party 3 supplies bad data then Party 2 sues > party 3 for breach.

>>8311313
What about when you have low value contracts with singular data sources. You essentially have an office space like situation where you steal small amounts of value over a long period of time this falling through the cracks.

>>8311334
Your welcome ;)

>>8310955

>>8311462
When you find out you again have irrefutable proof that the contract wasn't executed as arranged and have an open and shut case for breach.

Overall this makes the contract process more efficient and easier to find sources of problems and then come to a resolution quicker.

>>8311498
Agreed but if you’ve already extracted value and theoretically ran with it you’ve caused irreparable harm to the system because there were no human checks in place

>>8311443
one thing though, would supplying bad data regardless of intent (ie due to hacking or otherwise) enough grounds for suing? i just assumed that the party supplying the data would be held responsible for their own shit, and since the bad data would supposedly fuck everything up, they'd be liable for the damages caused. does that make sense

>>8311498
Why do you keep trying?

This dumb nigger doesn't understand that ChainLink is not in the business of securing some company's database.

If the company chooses to use a single, centralized source. ChainLink does not give a shit if that data is good or bad, it will do its job like intended.

Another question, why can't smart contracts interact with APIs directly?

What prevents an Ethereum contract from calling an API itself?

>>8311547
the human checks in place are the creators of the agreement. The suit would then be centered around the creation of the agreement. If the smart contract is bad itself then the people who are at fault are the attorneys and programmers of the contract. If you agreed to a faulty contract then it's your fault and you lose.

you just changed this from secured data source problem to a contract formation issue.

>>8311547
why would it be irreparable tho?

>>8311547

That’s irrelevant to the lawyer’s point. The point is, there’s value in being able to quickly and efficiently determine if a breach of contract has occurred. You’re really grasping at straws now man.

>>8311607
the fact that it is still tangentially related to chainlink just goes to show how fundamental oracles are to the smart contracts that everyone is clamoring about

>>8311565
If there's an agreement with the data source (assuming it's a 3rd party) and the party using the data, the data source then would likely be liable regardless of intent.between contracting parties and 3rd party data source would likely involve security of the data being provided.

>>8311586
ethereum contract can only interact with the eth blockchain, it needs an oracle to get data offchain

>>8311648
*the agreement between the contracting parties and data source provider would involve security of the data.

This FUD again, zzzzz.

>3rd part data source is still a centralized point of failure. Decentralizing the delivery method of that data is great and ensures security but the fact that the source of the data is still centralized

This is EXACTLY the oracle problem that link solves, and it solves because oracles have their output weighed against each other, to proide a weighted answer for the chain.

Just read the whitepaper.

>>8311650
Yea but why?

Can you not write code in an ethereum contract that makes an API call?

>>8311607
Nope I think i didn’t phrase my point succinctly. Let’s say there’s a smart contract process (Low or high value) with a singular data source that I have the resources to manipulate unnoticed for some time period. Let’s say I do that and extract the value and run with it. I’ve now caused harm to the system without facing the consequences because of this fatal flaw. Will I be sued and sought after, sure but if the monetary value of the hack is high enough then I can perform it and run with the money. This is a critical flaw that won’t make chainLINK this super ridiculous crypto that changes everything. Will it make smart contracts and blockchains useful? Absolutely but to think that it will apply to EVERY SINGLE industry is baseless hype if we can’t have a true end to end security

>>8311684
Currently smart contracts can't reach offchain data.

>>8311684
if that was possible, we would see some smart contract implemented by now, but we only have token-type contracts that interact only within the chain

>>8311684
ill try to answer anon but i dont know the technicals behind it, this one's out of my league. im not a coder. probably has to do with onchain vs offchain, and how blockchain works. i just take it for granted that an ethereum contract cannot interact outside the blockchain because if that wasn't the case Oraclize, ChainLINK, and other oracle services wouldn't have been made in the first place. sorry anon

>>8311734
It's would be less likely to happen now than before. It increases efficiency in finding these kinds of flaws.

There's immense value in making a contracting system like this.

No ones claim it's an end all be all but that doesn't mean that a much better system isn't going to have immense value.

>>8311769
>>8311740
i tihnk he wants to know exactly why it cant, ie the technical reasons.

>>8311740
>>8311769
>>8311780

Ok fine, Ethereum contracts can't get offchain data, got it.

Which leads to the obvious question of what if there is a smart contract platform that can? Then link will be useless

>>8311790
Ah maybe, not my area either.

>>8311734

The scenario you just described is easier to accomplish the way things are now though. It’s like you’re arguing against replacing horses with cars because cars can still break down.

>>8311814
>Ok fine, Ethereum contracts can't get offchain data, got it.
>Which leads to the obvious question of what if there is a smart contract platform that can? Then link will be useless
LINK will probably evolve into that platform as it grows.

>>8310468
OP irrevocably BTFO

>>8311814
Then I would probably a lot of my money in it.

>>8311814
you have aeternity with built in oracles. But you need to use aeternity blockchain only. But do you really believe everybody will be using one blockchain? There will be a series of private blockchains with some applications running on public ledgers. That's why investing in agnostic protocols like link and enigma is a no brainer.

>>8311814

You know how much bloat a decentralized oracle network would add to existing smart contract platforms? Aeternity is offering on chain oracles, but do you think the thousands of dApp developers working with ETH and NEO are going to move their whole project to AE when it’s easier to just implement a well-recognized blockchain agnostic off-chain solution?

>>8311876
Better point, you're likely going to want smart contracts that can interact with multiple blockchains.

>>8311814
because it isn't a simple task. i imagine those platforms have other priorities. scaling for example is something ETH has been dealing with for a while now (casper, sharding, plasma, pos, etc). they also need the decentralization aspect of it. i think it's better to ask why they wouldn't just use chainlink. i agree though, if they would build their own oracles then there would be no point to LINK. luckily since it's blockchain agnostic it can fit with any other blockchain/platforms if adapters are written for it. i think it's safe to assume that if a smart contract platform would have builtin oracles, those oracles can only be used in its own platform. if that isn't the case (if it's blockchain agnostic), and if it has an advantage over other smart contract platforms (scaling and what have you), then you just found the next 1000x investment, please share it with us. maybe a decent analogy would be like asking why won't businesses just make their own operating systems instead of buying windows. eh, i dunno but i think you get the point

>>8311092
I remember this fud in november. Jesus christ are you this stupid?

Yes, in the case of a single source API contract it is just as vulnerable as a centralized oracle. Which is why you have the option to choose as many API inputs as you want, depending on the level of security you want in your contract.

For a 500$ contract maybe you don’t give a shit and just choose one input. However for a 200m contract you can be damn sure it will have multiple independent and neutral inputs. What you are describing is not an issue with chainlink, but with the smart contract terms.

>>8310452
>>8310522

Name one piece of financial data that only comes from one or a few sources.

Ultimately you need centralized sources of information if you want to create something more than ponzi schemes or derivatives on other crypto assets, because there is no way to access information from the real word in a decentralized manner, at least in a cost effective way(Imagine everyone who has a wallet having to input data for all kinds of data thatk smart contracts on the blockchain could need, madness)

>>8312206
Bank account identifiers. There is only one unique identifier to each account maintained by a central database

>>8311188
Good point. There is literally no FUD left. What are we going to do now, fellow linkies? Other than buying more LINK.

SERGEY CAN YOU PLEASE LAUNCH THE MAINEEEEEEEEEEEEEET

>>8310468
single source data is all the value though. if you can get the data from any api, everyone will offer it and drive the price down to as close to zero as possible.

in the hypothetical world where swift uses chainlink, it wont even need to "stake" any link tokens, because users will have no choice but to trust the node and data if they want to use their chainlink oracle.

>>8312530
He was a college philosopher, he ate 130 big macs

>>8310946
Jesus Christ smartcontracts are going to mechanize and automate the entire fucking planet. Your fridge will be restocking itself, your autonomous car will be refueling itself, buying itself new breaks. Amazon-like delivery company will have contracts filled like orders which are automatically gathered and shipped upon receiving payment, etc...

>>8312412
That's not API data though, a bank account would be coded into the contract. API data is something that floats/changes. Think stock prices , weather, sports scores, interest rate changes, dividends%, bonds %. All these will be reported by multiple sources.

>>8312916
i'd love to be this blissfully ignorant. It must feel great right?

>>8310452

>The reason chainlink will ultimately fail will be because a 3rd part data source is still a centralized point of failure.

This is not what LINK is going to fix.

> It’s introducing a solution to a problem that ultimately cannot be resolved through decentralization

It's not introducing any problem? In that example, the issue exists no matter what oracle you use.

>>8310717
youre such a retard. the scenario we are trying to avoid with a centralized data source is if the data source gets the data right, and the oracle is compromised. If there is only one data source, then you'll never get away from trusting it. Also data sources are much more secure than oracles. brainlet u r.