Did this FUD ever get rebuked?

[Anonymous No.17349696]

>inb4 leddit
>inb4 6 months old

[Anonymous No.17349706]

>>17349696
>Reddit
Kill yourself

[Anonymous No.17349729]

>>17349706
Based

[Anonymous No.17349739]

>>17349706
>>17349729
lol

[Anonymous No.17349752]

>>17349696
Holy shit this guy figured it out

[Anonymous No.17349806]

Dishonest node operators won't be able to find people to stake their LINK on them for long

There's more money to be made in being an honest node operator

That's all I've got. I'm a layman so maybe someone more familiar with the technology can give deeper answers

[Anonymous No.17349816]

>>17349696

I suggest that nodes will be able to set the parameters for penalty trigger on their own. It is the only solution that makes sense. Users will be may choose between nodes with the most fair penalty conditions.

[Anonymous No.17349828]

It's a good point. The situation basically reduces to a Sybil attack -- having one entity controlling many nodes. One Chainlink proposed solution to this is certification. But this is a far from perfect solution. I guess it's also on the node operators to select jobs that don't seem suspicious. Another possible solution: a Kleros trial. If the data was coming from a faulty source, that's really easy to prove.

[Anonymous No.17349838]

>>17349696
There has to be regulatory legal framework to dispute and sanction this in the real world, code is law won't be the rule forever. And no it won't be a pajeet coin that'll handle these disputes. I think that's why SLAs and staking are taking forever, they're aware the space isn't mature enough yet. I think with high level agreements and stuff like isda and accord you'll see arbitration clauses etc. That's why the link will replace lawyers thing was always a meme, they'll still be guardians of the temple, but it'll make their lives easier and lawyers will need to understand code.

https://www.nortonrosefulbright.com/en/knowledge/publications/ea958758/arbitrating-smart-contract-disputes

[Anonymous No.17349877]

Yeah let me and my friends perform fraud in an environment where the entire process of fraud is registered on the blockchain and auditable by regulators, our identities known, and every component of our fraud registered on a global decentralised database that can't be censored.
It's the perfect crime.

[Anonymous No.17349913]

>>17349828
yeah great idea, the contract creator (who is in on the scam) will consult the help of a group of Kleros Indians to help thwart his own scam

[Anonymous No.17349987]

>>17349696
>p-please debunk this old fud i found on plebbit, which is where i, OP, the cocksucking faggot came from after the google pump middle of last year
lol

[Anonymous No.17350040]

>>17349987
Dilate tranny. I've been all in since the first day it hit etherdelta

[Anonymous No.17350106]

>>17350040
That's literally worse. Three years in this project and you don't understand anything.

[Anonymous No.17350137]

>>17349696
You have to go back

[Anonymous No.17350897]

>>17350106
So you understand why this is baseless FUD or a serious risk of exploit do you? Well which is it anon and why

[The Devil !!y9pM1O7kKh0 No.17350917]

>>17349696
Just sold all my LINK, thanks.

[Anonymous No.17351074]

>>17349696
If the nodes don't pick the specific job, how can they collude on a specific job?

[Anonymous No.17351101]

>>17349696
While you ask this to be debunked, I have a question for you. Please prove his idea is possible.
While we don't have access to nodes, to be nodes, to be certified, we actually don't have information how staking works, how it is distributed upon failure, rating systems and etc., we can't assume your little reddit FUD which gets tossed here around all the time, is true to the bone. Your FUD can't be truth, it's baseless without access to smartcontract platform and knowledge how it works.
Thus FUD you posted is considered false information and my node gives it -1 rating.
Now your node has bad rating, faggot.

[Anonymous No.17351111]

>>17349729
Yikes, is this the ultimate sell signal? The normans are here.

[Anonymous No.17351116]

>>17351074
I don't make the FUD my man, I just repost it

[Anonymous No.17351272]

>>17351101
Here's the proof: Chainlink has never released any documents on how they plan on being sybil resistant. Only vague explanations.

If someone has no proof that they've been able to solve one of the biggest problem in computer science, then they haven't. Simple as that.

Chainlink is a centralized, KYC ,vaporware scam. Hence why they have literally 0 users while plenty of people are using other oracles for their dapps.

[Anonymous No.17351707]

Reputation

[Anonymous No.17351742]

>>17349696
Chainlink is garbage and honestly really sad how zealot their community has gotten. There’s almost zero use for their token for common users and the cheaper the better from a tokenomics perspective. That said when the boys can’t hold back the sell wave this is going to 30 cents. There’s just not enough demand for such a shit project

[Anonymous No.17351798]

Yep. That's why Link is only temporary solution, Another better project will probably replace it in the coming years.

[Anonymous No.17352472]

>>17351707
Chainlink has no way to implement decentralized reputation. They simply don't know how. It's an unsolved CS problem.

None of their whitepapers covers it, except for some vague statements here and there. No actual specs or technical details. But low IQ non technical linkers like yourself think that a one page, vague, high level explanation of decentralized reputation means they've actually solved this age old CS problem KEK. Learn to code brainlet.

Chainlink is vaporware, KYC, centralized scam. Hence why literally not a single project uses them in production, everyone just makes their own oracles better than Chainlink's.

[Anonymous No.17352536]

>>17349739
>>17351111
Welcome to the board newfriends

[Anonymous No.17352669]

>>17351272
>If someone has no proof that they've been able to solve one of the biggest problem in computer science, then they haven't.
They clearly do have proof or companies like swift and google wouldn't be interested.
Things can be real even if they don't prove themselves to you, autism friend. You'll never grasp this concept but at least you've heard it now.

[Anonymous No.17352793]

Chainlink doesn't work you idiots, it's just vaporware

[Anonymous No.17353149]

Chainlink has a ton of business partners. What do they do for them? What product or services do they offer? Not in theory, but right now.

[Anonymous No.17353152]

>>17349696
You can't penalize an oracle for a dishonest/incorrect data source you pleb.

[Anonymous No.17353220]

>>17351074
>>17351116
pee pee poo poo

[Anonymous No.17353256]

>>17349696
congratulations op, you discovered the weak point of decentralization. time to sell all our crypto and put it back in the stock market. It goes up forever

[Anonymous No.17353291]

>>17353256
See >>17353152

[Anonymous No.17353361]

vaporware. sell your bags. it's all over for crypto. the hype is gone , only whales and institutional degenerate gamblers with excess FED money playing this garbage market

[Anonymous No.17353379]

>>17349877
kek

[Anonymous No.17353449]

>>17349696
Isnt that what TEEs are for? Theoretically, you cant even see or alter whats going on in a TEE on your own hardware. Thats kind of the entire point innit?

[Anonymous No.17353464]

>>17349706
>>17349729
Holy fucking shit is this guy based or what?

[Anonymous No.17353465]

>>17349828
This is not a sybil attack. Stop using words you dont know.

[Anonymous No.17353504]

>>17353465
It is a Sybil attack retard. A group of colluding nodes painting false data via a 51% attack

[Anonymous No.17353521]

>>17353504
What you described is explicitly NOT a sybil attack. Google is your friend.

[Anonymous No.17353527]

>>17353504
The nodes aren't painting false data, the data sources are.

The oracle nodes will not lose their stake because of error by the data source.

[Anonymous No.17353528]

>>17353504
THE ABSOLUTE STATE OF NULINKERS

[Anonymous No.17353551]

>>17353449
Yea. I don’t think there’s one solution to mitigate Sybil attacks. They seem to be taking a layered approach: TEEs and certification, mainly. I don’t think reputation really addresses Sybil attacks since one could build up their reputation with the intention of eventually corrupting a contract.

[Anonymous No.17353585]

>>17353465
How is it not? It’s one off-network identity behaving like many independent on-network nodes.

[Anonymous No.17353588]

>>17353521
It is a sybil attack brainlet, a majority of malicious nodes collude to penalise a minority of honest nodes


>>17353527
Wrong and you don't even understand the point you're trying (and failing) to rebut

[Anonymous No.17353690]

>>17351272
>>17352472
oh drop this stupid template you are using. You even press Enter at the same time.
Are you one of those "I made oracle over the evening last night"? Sound like it. You ask pretty basic question, these is no need to deep dive into code. You haven't read those papers.

[Anonymous No.17353827]

>>17353521
>>17353527
All this assumes that a group of nodes is colluding to paint inaccurate data by pulling from a false data source. It is still a Sybil attack but on a smaller level; they don't need to 51% the entire network, just the nodes operating over the nieche data feeding to the contract.

>>17353528
faggot

[Anonymous No.17353868]

>>17351742
Link sucks a fat wang and sergay is a slime ball who sells snake oil .

Imagine making a Statement how the ecosystem needs less tokens and platforms mean while your project uses tokens as a platform and an ICO got your rich

What a two faced jackal

[Anonymous No.17353911]

>>17349806
that's the same argument they give for dPOS, which we all know is shit.
>>17353465
It definitely is you retard. It implies oracles working together which is equivalent to being run by the same entity.

The last time this thread came up the main argument was that your stake only gets slashed for providing info that is not the API you promised to deliver. Which is fucking stupid because first of all nodes in one oracle all query different APIS (see whitepaper) and secondly there is no info at all about how staking punishment will work. But the node validating described in the whitepaper uses on-chain aggregation as the measure of correctness. Look it up.

[Anonymous No.17354033]

>>17353588
>Wrong
Except I'm right.

The oracle is in no way responsible for mistakes by the data source.
You absolute retard.

[Anonymous No.17354064]

>>17354033
where did this argument ever come from?
Correctness of the oracle is judged by aggregating with results from other oracles. It is literally in the whitepaper.

[Anonymous No.17354093]

>>17354064
>Correctness of the oracle
This is different from correctness of the data source.

My god is this place just filled with brainlets these days?

[Anonymous No.17354171]

>>17354093
If correctness of the oracle is judged by aggregating its published result only, that means the Oracle IS responsible.
Think, you absolute retard/troll.

[Anonymous No.17354267]

>>17353827
you could implement round based consensus. If you aggregate the result from multiple sources in and reach a consensus in the first round, you could have a certain timeout for entities to open a dispute on the consensus. If it's overturned, the false data reporting nodes lose the stake in its entirety.

[Anonymous No.17354274]

We did it Reddit. We created enough FUD to stop LINK from reaching $10 EOW.

[Anonymous No.17354300]

>>17349877

[Anonymous No.17354343]

>>17354171
>If correctness of the oracle is judged by aggregating its published result only, that means the Oracle IS responsible.
Correctness, sure.
But the OP is talking about LIABILITY; taking away money from the oracle for doing its job correctly.

[Anonymous No.17354350]

>>17354267
too slow.
The main argument in the whitepaper, as far as I can tell, is that the reputation system will be the main recourse for virtuous nodes.
Which means that you have to try and get staking jobs with them, not with nobodies. It is plausible that people will want jobs with high reputation providers and include one or two random small oracles (a minority) just as a safety guarantee and to save money.

[Anonymous No.17354365]

>>17354343
Correctness is fed into the reputation system.
Staking is not described in the whitepaper but they better come up with some good extra measures when they launch it.

[Anonymous No.17354412]

>>17354365
A node's reputation cannot be penalized either for doing its job correctly.
If the source feeds the oracle bad data, and the oracle correctly passes on that data, then the oracle is 100% blameless.

> they better come up with some good extra measures when they launch it.
Chainlink is in no way responsible for the variety, quality, number, ... of data sources.

[Anonymous No.17354443]

>>17354033
>This is your brain on down syndrome

[Anonymous No.17354469]

>>17354412
>A node's reputation cannot be penalized either for doing its job correctly.
Whitepaper says reputation contracts uses the aggregation info to judge. Reputation contract does not look at the APIs involved. You have a wrong conception of Chainlink.

[Anonymous No.17354485]

>>17354443
You're unironically retarded.

An oracle is merely a transporter. Transporters are not in any way responsible for the quality, authenticity, initial state, ... of the shit they transport.
Only for whatever happens during transportation.

[Anonymous No.17354490]

>>17354412
If you pick bad data feeds the blame is on you. And they are filtered out (by you, or you are filtered out) as time goes on.

[Anonymous No.17354499]

>>17353868
when the robots say "oh chainlink could solve this!" when really, it cannot

its time to sell. so sad. sergay could have open sourced his work and contributed to the community. instead greed. Sad!

[Anonymous No.17354512]

>>17354490
>If you pick bad data feeds the blame is on you
Typically the client picks the data feeds, not the oracle.

[Anonymous No.17354522]

>>17354490
picking back data feeds is not the issue. You may pick a good one but if you are being aggregated by bad nodes then your reputation (and possibly stake) will go down. See whitepaper.
This is why you shouldn't accept SAs with only small, unknown nodes.

[Anonymous No.17354529]

>>17354093
>>17354343
>>17354412

3 FUCKING POSTS of the essentially the same argument that are completely incorrect. Go back and read the whitepaper on how aggregation works from APIs and how outliers are punished whether they serve 'correct' data or not

Then dilate.

[Anonymous No.17354538]

>>17354499
>when the robots say "oh chainlink could solve this!" when really, it cannot
The solution to OP's bullshit is to use different data sources for a single input.
The only way to do this is to use a decentralized oracle.

That's why bZx for instance is famously switching to Chainlink after the recent attacks on the single illiquid price feed.

[Anonymous No.17354548]

Lets argue that an oracle should not be penalized if the data source provides the wrong data. How would that work?

A second node requests the API that provided bad data, and compares it to a list of good data? Then provides that response to a second smart contract that cancels out the penalty to the first.

But wait, that second contract was also fed bad data! Its oracles and smart contracts all the way down then.

[Anonymous No.17354559]

>>17354485
Jeez, dunning kruger is a bitch, eh?

[Anonymous No.17354566]

>>17354538
chainlink is just middle ware.

t. solidity dev

/thread

[Anonymous No.17354655]

>>17354529
>>17354469
>>17354559
They are obviously (OBVIOUSLY) talking about a simple situation where a number of oracles are using THE SAME SOURCE.
Obviously, in this case an outlier means it's the oracle who is faulty.

[Anonymous No.17354690]

>>17354655
But the situation in the OP describes a situation where they are clearly NOT using the same source.

No one is disputing that if they are all relaying from the same API then chainlink works as intended.

[Anonymous No.17354711]

>>17354690
>But the situation in the OP describes a situation where they are clearly NOT using the same source.
Yes, meaning an outlier is not necessarily a faulty oracle.

For instance, if all the other oracles assigned to that "deviant" source yield the same outlier data, then most likely the source is at fault.

[Anonymous No.17354740]

>>17354548
There are/will be numerous ways to compare input with output.

[Anonymous No.17354757]

>>17354655
No you weren't. Besides, that is not the premise of the fud and of chainlink as a whole. Chainlink wants nodes to use different sources. Again, it's in the whitepaper.
I realize now you're just baiting, final reply.

[Anonymous No.17354760]

>>17354711
No, you've not understood the scenario laid out in the OP. the malicious nodes are using a made up or 'secret' API where they are injecting the same bad data into their nodes. The honest nodes that are querying the correct API function normally but still gets penalised in this scenario, as they are outliers

[Anonymous No.17354775]

>>17354757
>Chainlink wants nodes to use different sources.
Yes, meaning you cannot simply look at outliers to determine whether it was the oracle that was faulty.

Stop being this fucking retarded, nobody is responsible for shit they cannot control.

[Anonymous No.17354796]

>>17354775
OK this has to be bait

[Anonymous No.17354799]

>>17354760
>the malicious nodes are using a made up or 'secret' API where they are injecting the same bad data into their nodes
Yes, and those nodes are ACCURATELY relaying the data to the contract.

Meaning they did their job perfectly, and therefore cannot be penalized.

[Anonymous No.17354805]

>>17349828
Vitalik has spoken

[Anonymous No.17354832]

>>17354796
It's not bait, it's just your brain that's so small and wormlike.

>hey mr oracle, you did your job correctly but we're going to fine you anyway
lmao you absolute shrimpbrain.

[Anonymous No.17354835]

>>17354760
he's just baiting.

[Anonymous No.17354843]

>>17354799
That's the fucking point you brainlet the malicious nodes don't get penalised and the HONEST ONES DO

[Anonymous No.17354851]

>>17349696
the answer is that nodes will not know for which contracts they deliver data
so if you deliberately give false data in hope to sabotage a certain contract you will burn a lot of money and reputation

[Anonymous No.17354870]

>>17354851
Nodes don't know but the requester does. The premise is that the requester picks 2 buddies and 1 honest node (or similar)

[Anonymous No.17354871]

>>17354843
You realize things like reputation and penalization are determined by the parties concerned, right?

Maybe you're so retarded that you'll accept responsibility for someone else's shit, but I can assure you not many will be that dumb.

[Anonymous No.17354948]

>>17354843
>the malicious nodes don't get penalised and the HONEST ONES DO
There aren't actually any "malicious" nodes in OP's scenario.
In OP, all nodes do their jobs correctly, it's just that the "victim" nodes are assigned to a malicious source.

[Anonymous No.17354973]

>>17354835
t. brainlet cope

[Anonymous No.17354982]

>>17354948
read the OP moron, literally step 1:

>1. Collude with a group of nodes

[Anonymous No.17355010]

>>17354982
Yes, there are colluding nodes.
But all nodes in OP do their job correctly, so none of them are actually "malicious" in the sense that they tamper with any data.

The only tampering is at the level of the one data source assigned to the "victim node".

[Anonymous No.17355033]

>>17354851
i guess their could be jobs like this, but i don't think they really know for sure how this will look like in the end since nobody done anything like this before
i could imagine that it would be possible but then node operators wouldn't take jobs like this were nodes are specifically chosen especially if the number of nodes is that low

[Anonymous No.17355053]

>>17355033
meant for >>17354870

[Anonymous No.17355072]

>>17354948

>>17354871

>>17354973

>>17355010

[Anonymous No.17355097]

>>17355010
operating on that assumption the faulty data source would have to establish itself as a trusted data source first that would allow the nodes to operate with a profit in the first place. It would never establish itself as a trusted data source without providing data that will provide a profit without reasonable certainty.

So that trusted data source would have to go rogue. And assuming the nodes are not colluding, then there would have to be collusion amongst multiple trusted data sources to provide the 51% of nodes with the false data.

Is it possible? Sure. But I'd say that's incredibly unlikely, assuming the oracle network is fully established.

[Anonymous No.17355099]

>>17355072
lmao, I can see your ears go red from here.

You just realized I'm right and now you're trying to salvage some ego with a zero-effort response.
It's ok bro, we all anon here.

[Anonymous No.17355122]

>>17355033
I mean, you could just make a lot of low-reputation nodes.
This is why node operators should be able to see the (average) reputation of the nodes they're working with imo

[Anonymous No.17355162]

>>17355097
Exactly.

Especially for financially significant contracts, sources are actually a lot more likely to be actually known entities (exchanges, banks, credit-rating agencies, ...), so reputation and accountability will apply.

[Anonymous No.17355200]

>>17355097
>>17355162
Plus, even for unknown data sources, an on-chain trust rating system could/should be set up very easily.

[Anonymous No.17355265]

Wouldn't experienced honest node operators decline contracts based on penalties susceptible to a 51% attack?

[Anonymous No.17355302]

>>17349696
This is a pretty basic attack scenario, where the attacker controls the requesting contract, the majority of the nodes in a quorum, and the endpoint. I think there are a few layers to a solution for this:
- Reputation works both ways. There's no reason a reputation provider cannot also track the requesters themselves, such that nodes can be configured in a way to not accept service agreements from requesters with no history or who are not registered with a reputation provider that they are on. Obviously this doesn't prevent a requester from creating valid requests to their own nodes to establish history, but it raises the barrier to entry as the reputation provider can act like a filter to prevent malicious actors. It could also be possible for reputation systems to require additional deposits from both requesters and node operators and provide their own dispute resolution protocol outside of the service agreement.
- Nodes will need to be able to be configured to blacklist addresses of other nodes in the service agreement. Oracle addresses is already a field in the service agreement payload so this shouldn't be difficult. By also implementing a p2p gossip protocol and allowing node operators to configure some as trusted addresses, it could allow for the blacklist to grow without a node having to be negatively affected by the malicious actor first.
- API providers need to sign their responses. This helps weed out malicious API providers like the one used in this scenario. The difficult part here is what to do with those signatures, since sending and validating each one on-chain would be expensive. This is also where a reputation service can come in and help with establishing reputation of the API providers as well.
Ultimately it all boils down to Chainlink creating a web of trust (sound familiar?) between node operators, requesters, and API providers, which is what they seem to be doing already.

[Anonymous No.17355372]

>>17355302
In OP's scenario, the only deviant input is coming from the "victim" nodes all querying the same source.
Obviously that indicates it's the source that's faulty.

No node will accept responsibility for the source data's correctness.

[Anonymous No.17355388]

>>17349706
B-B-B-B-B-BAAAAAAAAASED!!!!!!!!!!!!!!

[Anonymous No.17355412]

>>17355372
They wouldn't need to with signed responses. Only that the response they wrote on-chain matches what the API provider signed.

[Anonymous No.17355563]

>>17355162
>>17355200
So why would multiple trusted data sources ever threaten it's own reputation amongst operating nodes? They stand to lose business if they were to cheat the system and provide unreliable data. Plus they wouldn't even see the rewards the oracle would pull unless they had some sort of performance arrangement with the operating nodes.

If anything it would result in an unsubscription from the data providers services, because why would you trust a data source that occasionally provides false data?

[Anonymous No.17355639]

>>17355563
exactly

Just like motorized cars changed roads, decentralized oracles will change the source/API landscape with more redundancy, decentralization, reputation, ... at the source level, making it harder for them to be malicious.

[Anonymous No.17355746]

>>17355639
I'm confused. I thought we were arguing.

Alright, well I'm still calling it a sybil attack. The vector of the attack is just from the data source on the target network nodes.

[Anonymous No.17355766]

can somebody post the positive thoughts copypasta?

[Anonymous No.17355827]

>>17355746
>I'm confused. I thought we were arguing.
You're saying the attack in OP is at the source level, and I agree.
You're also saying disreputable sources are not likely to be used in financially significant contracts, and that reputable sources are not going to shit up their reputation for quick gain.
I agree with all these things.

[Anonymous No.17355935]

>>17352669
>They clearly do have proof or companies like swift and google wouldn't be interested.

Where is the proof then? Also, SWIFT and Google will never use your shitstink.

[Anonymous No.17356090]

>>17354832

It's not about whether the oracle did it's job correctly nor not but if the oracle is in the minority or not. The minority gets punished, it's that simple.

[Anonymous No.17356106]

>>17355766
https://www.youtube.com/watch?v=62BN2cCiUaQ

this one?

[Anonymous No.17356296]

>>17356090
>It's not about whether the oracle did it's job correctly
But of course it is.
That's the only thing this is about.

>The minority gets punished, it's that simple.
Because the white paper says aggregation is the only way to determine faulty oracle operation, riiiiiiiiiiiiiiiiiiight?

Well the white paper says the following:
"Detecting outlying or incorrect values is a problem that is specific to each type of data feed and application. For instance, detecting and rejecting outlying answers before averaging may be necessary"

Now tell me how "the minority gets punished" when the outlying or incorrect values are detected before averaging even takes place?

You read a simple scenario in the white paper (outlier means oracle fault) and took that as the gospel, completely disregarding basic common sense and even the rest of the white paper.

[Anonymous No.17356329]

this is a good discussion. it makes me want more link.

[Anonymous No.17356571]

>>17355746
>>17355827

Get a room faggots