[ 3 / biz / cgl / ck / diy / fa / ic / jp / lit / sci / vr / vt ] [ index / top / reports ] [ become a patron ] [ status ]

/biz/ - Business & Finance


View post   

File: 113 KB, 1056x594, the-three-body-problem.jpg [View same] [iqdb] [saucenao] [google]
23195421 No.23195421 [Reply] [Original]

>The “Oracle Problem” is a three body problem: data source, oracle, and on-chain data consumer. Existing solutions succumb to the pitfall of modelling their ecosystem as being solely composed of oracles and data consumers, while ignoring where the data originates from
https://medium.com/api3/the-api-connectivity-problem-bd7fa0420636

>> No.23195435
File: 135 KB, 735x459, myth-oracle-delphi.jpg [View same] [iqdb] [saucenao] [google]
23195435

>>23195421
>In other words, their models inaccurately treat the oracle node as the mythical oracle that is the source of the truth, rather than what it really is — something that transports data from source to blockchain.

>> No.23195457

>>23195421
In other words, someone will put a woman in charge and ruin the world?

>> No.23195474

>>23195421
>>23195435
>Aggregation

>> No.23195530
File: 11 KB, 530x387, L-curve-of-an-ill-posed-problem.png [View same] [iqdb] [saucenao] [google]
23195530

>More essentially: the oracle problem is ill-posed — its name suggests an impossible solution. An analogy would be to approach the problem of getting from Point A to Point B as the “teleportation problem”. Further, ideal architectures for solving the oracle problem drastically change depending on the data type at hand

>> No.23195565

>>23195530
>Such a problem inevitably leads to impractical and/or sub-optimal solutions.

>> No.23195779
File: 102 KB, 1501x1005, Price_Listing_Pair_Page--1-.png [View same] [iqdb] [saucenao] [google]
23195779

>>23195474
>A price feed fed by 10 oracles (for example) does not represent 10 unique data points. All oracles could very well be serving data from the same API provider (and we’d be none the wiser).

>> No.23195797

>>23195779
When moon?

>> No.23195851
File: 10 KB, 284x260, schelling_focal_point.jpg [View same] [iqdb] [saucenao] [google]
23195851

>>23195779
>Oracles have an incentive to gather cheap and easily accessible data because nothing is enforcing or incentivizing them to do otherwise--since, again, they are not enforced in any way to report their sources. This creates something of a Schelling point around cheap and easily available data.

>> No.23196120
File: 88 KB, 800x742, 369.jpg [View same] [iqdb] [saucenao] [google]
23196120

>>23195779
>Further, this makes staking difficult, if not impossible, in such systems because now high-quality, curated data sources become outliers.

>> No.23196152

>>23195457

Yeah Merkel is doing such a shit job, women are terrible.
Grow up you fucking incel

>> No.23196201

>>23196152
She is though

>> No.23196245

>>23195779
>Doing source-blind aggregation shows, what can only be called, statistical illiteracy. Like already mentioned, a data feed being served by x oracles does not necessarily correspond to x unique data sources.
>This means a data-source agnostic aggregation method results in a skewed aggregate result

>> No.23196254

>>23195421
I'd like to solve the connectivity problem with Sasa. If you know what I mean.

>> No.23196265

>>23196120
>>23195851
>>23195779
>>23195565
>>23195530
Those are legit criticism, but I would assume that longterm the better nodes will be selected.
Remember that the oracle network doesn't have to be perfect in theory, it just has to be perfect in practice. If it works, it works.

But are you basically telling us to buy kleros?

>> No.23196362

>>23196265
>But are you basically telling us to buy kleros?
I'm not telling you to buy anything.

>> No.23196398

> three body problem
chink detected

>> No.23196690
File: 61 KB, 1144x1144, eth_usd_price_responses.png [View same] [iqdb] [saucenao] [google]
23196690

>>23195779
>Another problem with source-agnostic aggregation is the inability to do a properly weighted and normalized aggregation. Consider, a price feed contract served by data from price aggregator APIs: oracle responses occur at different times, prices represent different trading volumes, and these prices come from different aggregators (certainly with their own proprietary aggregation methods).
pic related

>> No.23196710

>>23196690
>Blindly computing a mean or median on these data points is doing an “apples-to-oranges” comparison. That is, you are essentially computing a statistic on different data types but implicitly treating them as if they were the same — something that is clearly ill-informed to an average data scientist.

>> No.23196911

>>23196362
What's your overall message?

>> No.23196915
File: 1.84 MB, 400x400, niggersfeedingreptilian7.webm [View same] [iqdb] [saucenao] [google]
23196915

>>23196690
Burat sucks gypsy dicks in Hell.

>> No.23196992

>>23195851
>reputation system
Oracles are not all the same. They each have a unique reputation dependent on how well they’ve done. If they serve inaccurate data their reputation is destroyed. Also, oracles that use high quality data can advertise that fact to be used by higher value contracts.

>> No.23197118

>>23196911
Not everyone on this board wants to shill you something (though this is rare), just go out sometimes i guess

>> No.23197145

>>23196992
>They each have a unique reputation dependent on how well they’ve done.
Pray do tell: how does one quantify "how well they've done"?

>> No.23197152

>>23197118
he's trying to shill something the honeycomb guys are working on

>> No.23197184

>>23196710
why do you trust a womens opinion on an issue that requires critical thought?

>> No.23197237
File: 166 KB, 640x431, epidauros2.jpg [View same] [iqdb] [saucenao] [google]
23197237

>legal repercussions of data source agnosticism
>Most API terms of service prohibit the resale or unauthorized distribution of the API data, which positions an oracle node operator serving such APIs to be in breach of those terms and susceptible to broad sources of legal liability including claims by the API provider

>> No.23197684

>>23197237
> resale or unauthorized distribution.
So if a node breaks the law it's in trouble but assuming that the node doesn't have a distributive agreement is hasty.

>> No.23197809

Kek, just printed your white paper. But I am not sure whether I should even bother reading it now that you are shilling this on biz.

>> No.23198562

>>23195779
what are signatures signed at the source and the open source framework of ChainLink that allows contract creators to decide whatever level of decentralization they feel meets their security demands in securing the value of the contract. Like Sergey states numerous times, this is an open ended question

>> No.23198612

>>23195421
There is no oricle problem man. Its fucking over, and even if it was solved Token is not needed

>> No.23198618

>>23197809
spark?

>> No.23198628

>>23198562
If signatures are signed at source, why not have the source deliver the data directly rather than a number of middlemen?

>> No.23198645

>>23195421
the real oracle problem is nobody needs oracles for shit

>> No.23198670

>>23198645
Perhaps. There's some interesting research suggesting Uniswap is a good price oracle, in which case you would have an on-chain price reference point. Related: https://medium.com/gauntlet-networks/why-is-uniswap-a-good-oracle-22d84e5b0b6c

>> No.23198676

>>23198628
or let you query the source (authenticated by the issuing authority specified by the contract) and let interested parties (you) drive your end of the smart contract from your mobile phone?

>> No.23198728

>>23196152
>Yeah Merkel is doing such a shit job, women are terrible.
This unironically

>> No.23198998

>>23196398
i read the book and i liked it. im whiter than you also

>> No.23199070

it’s not a three body problem, it’s a four body problem. an oracle network isn’t just a conveyor belt, it’s a TEE made trustless, confidential, and reliable through distribution

>> No.23199092

>>23195779
I’ll byte. Api3 shifts work away from operators to api providers. Both can be corrupt. What do?

>> No.23199160
File: 131 KB, 1800x833, F1.large.jpg [View same] [iqdb] [saucenao] [google]
23199160

>>23199070
Based on your post, I'm guessing a z-score in the range of (-1, 0.5).

>> No.23199190

>>23199092
Section 6: Quantifiable Security through Insurance

>> No.23199236

>>23199160
showing your belly already, looks like I win

>> No.23199311

>>23196710
but for Chainlink, as argued by your previous points, they ARE the same APIs for high-quality nodes.
In effect with staking the incentive becomes simply to use trustworthy APIs. If an API is compromised the involved nodes will pay out the lost money, lose reputation, and move on to either more APIs or better ones.
So you Shelling point argument >>23195851
also does not hold with Staking.

And in fact the oracle query time is simply assumed to be close, and while trading volumes are different the actual data they approach should be the same (the ideal price).

>>23197237
this one is just stupid since the oracles have agreements with their API

The funny thing is that API3 talks about the oracle problem being imaginary but they themselves create an ADDITIONAL problem which is in fact imaginary. API agnosticism is not a problem at all.

But nice attempt at getting a market slice of the oracle market. Doomed for failure but who knows.

Good luck.

>> No.23199438

1) service agreements stipulate sources, the contract creator has complete control of which sources are accessed
2) Chainlink is literally courting high value data feeds to guarantee high quality data and end to end quality
3) discord faggots have never done anything of value except for retarded misfires like Lenocineum.com, despite having been around since 2018

>> No.23199476

>>23199311
>they ARE the same APIs for high-quality nodes
so multiple oracles are reporting data from the same source?

>incentive becomes simply to use trustworthy APIs
so the schelling point becomes trustworthy APIs? and how do these anonymous, distributed nodes converge on the most trustworthy API?

>with staking
any insights into how staking will be implemented in such a system? will it be an outlier-removal method? or something else?

>actual data they approach should be the same (the ideal price)
then you should see a normal distribution here >>23196690

>the oracles have agreements with their API
why would an API have third-parties sell their data (often multiple times per API call) rather than simply monetizing their data/services per call via running their own oracle

>> No.23199501

>>23199438
>service agreements stipulate sources, the contract creator has complete control of which sources are accessed
there is nothing that enforces the nodes to access the data you request them to access. unless the API provider signs the data, in which case you might as well get the API provider to supply the data directly to the blockchain

>> No.23200067

>>23199501
But why can't APIs just sign the data for the nodes yo?

>> No.23200158
File: 20 KB, 486x314, EQnJasjUUAAblGi.jpg [View same] [iqdb] [saucenao] [google]
23200158

>>23200067

>> No.23200200

>>23200158
Why does this mean? Do band help bowl?

>> No.23200255

>>23200158
Is this why Johnny rim hoers

>> No.23200288

>>23199476
oh, so you're just retarded.
too bad your fud had some promise.

>> No.23200448

>>23199311
>API agnosticism is not a problem at all.
because it's a matter of accuracy/security through obscurity, right?

>> No.23200453

>>23200288
No your retarded you bhanchod basterd madrachod

>> No.23200533

Bullish for Kleros. Human nodes feeding data into an oracle network are the future.

>> No.23201358
File: 267 KB, 640x653, Serjeet Nazaresh.jpg [View same] [iqdb] [saucenao] [google]
23201358

>>23195421
>Existing solutions succumb to the pitfall of modelling their ecosystem as being solely composed of oracles and data consumers, while ignoring where the data originates from.
Which 'existing solutions' is she referring to here? Chainlink is the leader in the space and they've been beating the data quality drum forever.

>> No.23201430

Then if they are so transparent why won't make the sources of their data feeds public?
this is a common problem with middleman builds

>> No.23201474

If the data quality is SO good then publish it, show the quality for all to see.
since that's not being/cant be done this makes people ask questions

>> No.23202002

>>23197118
That doesn't answer my question and I was being mostly ironic when I talked about kleros.
My question is whats the tldr of your whole diatribe

>> No.23202649
File: 1.29 MB, 1015x1024, 0B874B44-D1D0-4069-8AB3-38A4A0F28F01.png [View same] [iqdb] [saucenao] [google]
23202649

How many times have we seen someone explaining why Chainlink is shit, only to eventually bend the knee and then fade into complete irrelevance? Drns

>> No.23202760

>>23199190
>Section 6: Quantifiable Security through Insurance
Section 6 of what?

>> No.23202776

>>23199501
Holy fuck lmao we're back to 2017 fud. Is the circle complete? Is it time?

>> No.23202828
File: 836 KB, 626x680, 1577257429714.png [View same] [iqdb] [saucenao] [google]
23202828

look out guys its the Burek and Timo gang, back to beg for money with another half baked idea we wont follow through on
we swear this is the one, we dont even care that Sergey ignored us, this totally isnt a salt driven project

>> No.23203004
File: 393 KB, 810x1282, 2-of-Swords---Peace.jpg [View same] [iqdb] [saucenao] [google]
23203004

>>23202649
>>23202760
>>23202776
Thank you for your high-calibre contributions to this thread, friends.

>> No.23203160

>>23203004
You come at us with retarded shit that was argued about literally three years ago and expect sincere engagement.

>> No.23203178

>>23203004
kys

>> No.23203563

>>23201474
Security issue. If you know where the data is from then you can try to hack it and it fucks it up. The API connectivity problem is a non-existent. Chainlink nodes solve this already and each use different sources. Only so many sources can be on each node. They don't tell you which ones because it would create an attack vector which would be created with API3. Also Chainlink allows first party nodes, just these providers would then need to deploy additional infrastructure or change their business model. Data providers can also choose to operate a API3 requires all data providers to deploy and maintain oracle node infrastructure themselves, increasing costs and friction. Data from data providers who do not operate an API3 node is simply unavailable to users.

>> No.23203581

>>23202828
exactly. call me when they have more than a whitepaper and website. what is this 2017? Get a few users then do a token sale

/thread

>> No.23203687

>>23199092
They're actually planning on using fucking kleros lol. This and the terrible biz shilling. You guys could do better than this low effort cash grab.

>> No.23203714

650,000,000 non-circulating

Six hundred and fifty million LINK tokens (65% of the total supply) are not in circulation.

>> No.23203752

>>23203563
>Security issue. If you know where the data is from then you can try to hack it and it fucks it up.
I thought Sergey himself said something about "security through obscurity" being a bad thing? Further, do you think hacking a professional API provider is trivial? Regardless, see: Quantifiable Security through Insurance

>Data providers can also choose to operate a API3 requires all data providers to deploy and maintain oracle node infrastructure themselves, increasing costs and friction.
See: Airnode https://github.com/api3dao/airnode

>Data from data providers who do not operate an API3 node is simply unavailable to users.
So API providers have a choice: they can deploy a self-maintaining Airnode and be proportionately compensated for providing data to smart contracts, or they can sell a subscription to a third-party oracle that will resell their data potentially countless times per API call.

>> No.23203778

>>23203714
I would much rather have those tokens being held by the Chainlink team vs the public that will just use the tokens to pump and dump over and over.

>> No.23203783

>>23203563
>Chainlink nodes solve this already and each use different sources. Only so many sources can be on each node.
I can't parse this thus didn't respond.

>> No.23203913

>>23203778
>coping THIS hard

>> No.23203926

>>23203752
>I thought Sergey himself said something about "security through obscurity" being a bad thing?
In the regards of someone like Compound or Maker which will not let you know who the nodes are

>See: Airnode https://github.com/api3dao/airnode
This requires hiring a team or person to manage this

>they can sell a subscription to a third-party oracle that will resell their data potentially countless times per API call.
Wouldn't they all choose this option? Economically this would be cheaper for them

>I can't parse this thus didn't respond.
wdym

>> No.23203993

>>23203783
other questions

1) How long until developers can use this

2) How long until data provider can be an airnode? I would think if this isn't vaporware you would have onboarded these first before a token sale

>> No.23204032

>>23203926
>In the regards of someone like Compound or Maker which will not let you know who the nodes are
And obscuring the data sources is different in what regard?

>This requires hiring a team or person to manage this
It doesn't, refer to the documentation.
>Airnode is a fully-serverless oracle node

>Wouldn't they all choose this option? Economically this would be cheaper for them
I don't think you understood my point: an API provider can earn more by selling their data on-chain, per-call (or per subscription) versus having a third-party oracle re-sell their data on-chain

>wdym
I didn't understand your comments.

>> No.23204078

LINK HOLDERS UTTERLY BTFO

>> No.23204084

>>23203993
>How long until developers can use this
Directly related to (2)

>How long until data provider can be an airnode? I would think if this isn't vaporware you would have onboarded these first before a token sale
Maybe you didn't read the documentation or maybe you don't know what serverless technology entails. See: How long until data provider can be an airnode? I would think if this isn't vaporware you would have onboarded these first before a token sale

>I would think if this isn't vaporware you would have onboarded these first before a token sale
Data feeds are insured. This necessitates an insurance (also staking/rewards) pool that necessitates a token sale.

Thank you for your questions :)

>> No.23204110

I meant: See: https://github.com/api3dao/airnode (copy-pasted the wrong thing)

>> No.23204162
File: 191 KB, 1848x1334, airnodegithub.png [View same] [iqdb] [saucenao] [google]
23204162

>>23204110
I see this but what am i supposed to do with this to help me understand?

>> No.23204194

>>23204110
what do current Chainlink data providers say to this when you show them?

>Data feeds are insured. This necessitates an insurance (also staking/rewards) pool that necessitates a token sale.
So they need to be insured before depploying an airnode? I'm just saying that having X data providers MOUs ready to deploy would be a big selling point for a token sale. Otherwise sounds like vaporware

>> No.23204201

What's your plan to on-board api providers to run their own air node?

How would an api provider running their own air node be different than running their own chainlink node?

>> No.23204227
File: 35 KB, 626x506, Screen Shot 2020-10-11 at 10.05.55 PM.png [View same] [iqdb] [saucenao] [google]
23204227

>>23204162
Basically: an oracle operator doesn't need their own server and database. They deploy their node via a cloud computing endpoint. The node is designed such that's it's self-maintaining. "Set-it-and-forget-it" you could say.

Thanks for your interest.

>> No.23204256

>>23204201
See:
>>23204227
Running a self-maintaining, serverless node is drastically different than having to maintain your own infrastructure (server+database, at the very least) to run a node.

>> No.23204259

>>23204227
Most data providers are DevOps people, so why is this the biggest hurdle? I don't see that this is really an issue to run a node or just sell the data to a Chainlink node

>> No.23204300
File: 179 KB, 700x490, 42.png [View same] [iqdb] [saucenao] [google]
23204300

>>23204259
I'm off for tonight, but I'll direct you to Section 4.2 in the API3 whitepaper: https://api3.org/

>> No.23205800
File: 102 KB, 350x263, 1601685359735.jpg [View same] [iqdb] [saucenao] [google]
23205800

>>23199501
>there is nothing that enforces the nodes to access the data you request them to access
nigga do you know how to read? let me green text it for you
>service
>agreements
>stipulate
>sources
>contract
> the creator
>has complete
>control
>of which
>sources
>are accessed

>> No.23206570

>>23204259
Say there are ten nodes which provide price feeds for Shitcoin.
8 of them just look at the "exchanges" tab on etherscan and average the prices from that.
You have your own exchange. You can provide your pricing data. However, you notice that occasionally (1 in 50 times) your prices don't match up and you would lose LINK.
You have no reason to provide your data. You are much better off doing what everyone else is doing - aggregating the etherscan data and collecting the free linkies from sergey, because you won't have your stack slashed that 1 in 100 times.

The shelling point converges at the api which is easiest to access and run a node for. There is a HUGE incentive to provide the exact same data as everyone else - aka, use the exact same source. This is what is currently happening with link nodes. There is no reason to provide new data, and you will even lose money in the long run if you try to do so. As such, the outcome becomes centralised and therefore easily manipulable and defeats the whole purpose of LINK. You might as well just hitch your prices directly to etherscan because you'll get the same number.

>> No.23206627

>>23204300
no team page. wonder why

>> No.23206694

>>23206627
It's a DAO-governed project. It's not quite apropos to have a team page. Feel free to google the whitepaper authors however :)

>> No.23206707

>>23206694
i know one of them personally, and i dont have anything positive to say

>> No.23206732
File: 216 KB, 607x608, fear the strong.jpg [View same] [iqdb] [saucenao] [google]
23206732

>>23206707
>i know one of them personally, and i dont have anything positive to say
story time?

>> No.23206734

>>23195421
>>23195435
B-but why would we need blockchains in the future? Why is Oracle Problem even a problem when blockchains will be obsolete?

>> No.23206742

>>23195851
This part isn’t necessarily true in practice. In the game theory environment nodes have against one another, they realize that going for cheap data MAY pay off, but ultimately nodes will likely seek the most accurate (i.e. high quality) data in order to not swing from that accurate point in either direction (variance). I agree it’s somewhat of an “if” but in the end it’s more likely than the latter possibility. In the long run, more accurate nodes are selected for better jobs, so they are incentivized to provide high quality data

>> No.23206876

>>23206742
Thanks for a quality post, unironically. Yes, there is nuance to the problem because we are making assumptions about node operator behaviour.
>but ultimately nodes will likely seek the most accurate (i.e. high quality) data
This assumes the node operators have the statistical know-how to distinguish bad/better/good data sources. E.g. CMC recently introduced a lot of clever algorithms for identifying volume inflation (since exchanges are incentivized to inflate volume numbers for optics); see: https://blog.coinmarketcap.com/2020/05/13/ongoing-improvements-to-combat-volume-inflation/
Would node operators independently decide to switch to a better data source once it appears? Would they be keeping up to date with such announcements?

>> No.23206964

>>23206570
are you saying that link operators are in a race to the bottom to get the crappiest data

>> No.23207112

>>23206964
Nodes are incentivised to use the exact same sources as other nodes, and punished for actually providing original data. So yes.

>> No.23207176
File: 242 KB, 500x500, 1601224919948.png [View same] [iqdb] [saucenao] [google]
23207176

this thread is unironically bullish for my stinkies

>> No.23207217

>>23207112
Nodes have their data sources stipulated in the SLA. It's not like each node operator shops around for the "best" data. Nodes will pull from whatever sources they're told to.

>> No.23207317

>>23207217
Do you have a link to said SLA contract?

Further, let's say the user specifies which sources they want nodes to pull from. Would said user prefer to get that data from third-party oracles? Or would they prefer to get signed data from the data source(s) directly (since they are already implicitly trusting the data source)?

>> No.23207424

>>23206876
what makes good data "good" then?
>>23207176
this. healthy competition will bring the best.

>> No.23207497

>>23195421
Oracles are so Q2 2019 desu.

PlotX is next. (tomorrow)

>> No.23208214
File: 539 KB, 1122x688, 03F606AF64F5417D9AE3797A76BE3B00.jpg [View same] [iqdb] [saucenao] [google]
23208214

>>23207424
> "consume or be consumed" Sloppy Sergers, Pleb Plaid Burger Meister PhD.

>> No.23208304

>>23196152
Your country is non-white this generation. Not next. This.

>> No.23208354

>>23207112
This. Look at Facebook. They get their data from authority, from the “experts” like world health, china, their own paid-for authorities. Then they self validate. And where do most people get their data from. Authority, the familiar name brands like nbc, cbs, cnn, Fox. You get a few decent sources of info, but rarely do people read and evaluate. They simply consume data like their food which has little nutritional value.

>> No.23208362
File: 46 KB, 480x360, 42 (37).jpg [View same] [iqdb] [saucenao] [google]
23208362

>>23208354

>> No.23208389
File: 78 KB, 1000x600, 20201011_201008.jpg [View same] [iqdb] [saucenao] [google]
23208389

>>23195421

>> No.23208428

>>23207424
Good data fits reality at the very least, but I’d argue good data predicts future events. Yield inversion predicted A depopulation event months ahead of covid and has been even predicting recessions months in advance for the last few decAdes. Poor data is easy. Poor data causes loss of money. You see all the countries pushing money into the system due to covid While still maximizing human loss. That’s poor data. You don’t want poor data.

>> No.23208532

>>23208428
But here’s the thing. The data you and I get are months old. Even the present you realize as the “now” is actually the past. You are staring at the screen now, but the you who decided to stare at the screen now was made up as a thought seconds ago, and even that person was a creature spawned from habits years ago who was made up of a series of programmed data that was spoon fed by various inputs from school or friends or something you read. So really the you now isn’t you now but you from a past to made a series of choices in his mind to be here now.

>> No.23208563

Imagine a decentralized exchange that didn't rely on oracles to determine the token price?

>> No.23208700

>>23196245
This is hilarious how retarded it is. Turning a benefit into a negative, definitely the work of someone who can’t compete in the oracle marketplace.

>> No.23208908

>>23207112
Staking isn’t here yet, and there’s no deterministic penalty for providing data outside of the median value to the aggregator contracts, so how exactly are nodes incentivized to produce the same exact data?

The median value is used to protect against Sybil attacks, since the median is always the middle of a sorted array, then attackers have to pay off exactly one more than half of the nodes to manipulate the price. Having varied price sources is a benefit because it doesn’t rely on one data source to fuck everything up.

>> No.23209053

>>23207317
The user wants data from an arbitrary source. The user doesn’t want to wait for every api provider to deploy a node to write their data on chain, they want a mechanism by which any api call can be piped into a smart contract function call. Signed certificates from the data source are coming, isn’t that part of DECO?

>> No.23209181

>>23199476
>why would an API have third-parties sell their data (often multiple times per API call) rather than simply monetizing their data/services per call via running their own oracle

They will simply monetize their data/service per call via THEIR chainlink node.

>> No.23209361

Holy shit, this article is trash. Do you fucking scumbag eastern euroniggers understand that your entire premise collapses within even the tiniest of scrutiny?

>1. linearly increasing node count doesn’t linearly scale accuracy because of a lack of transparency
So how do you know that not all of the data sources are unique? Is it not possible that different sources have the same price? The lack of transparency doesn’t prove the sources are the same or unique, and it wouldn’t matter if it did, because what’s more important than unique data points is RELIABLE, UNALTERED delivery of the source data to the blockchain. As of right now, redundancy is added security, but that’s just one part of defense in depth.

>2. Incentive for cheap data
Kek. This is where it all makes sense. My guess, someone bought an unaffordable amount of authenticated API access and the market isn’t ready to buy their data yet. But I’ll bite, Sasha, why are nodes incentivized to provide cheap data?

>3. Cheap data is favored because it’s more prevalent
Do you know what a weighted average is? You must, given the next point.

>4. Prices don’t take into account volume
LinkPool has volume-weighted price feeds. There’s literally no reason why this isn’t used in blockchain other than because it’s not needed yet. Who’s going to buy your data, faggot? Who exactly needs expensive data on the CryptoKitties world pc?

5. Legality
Guess I don’t have much to say on this one, other than if an API company starts suing node operators then they’ll finally see the financial value of providing their apis on chain, and they’ll be able to spin up a chainlink node within an hour to pull in that extra income. Why the fuck is something else needed when they can unironically pull a Docker image and do it securely and efficiently, right now?

>> No.23209432

>>23196690
>deploys a new aggregation contract
Wtf do you do then? Again, medianizer is for Sybil resistance, not for a statistically robust price analysis. You guys must be outright scammers. There’s no other possibility. There’s no way that you get as far as you did with chainlink nodes without knowing the most basic of things.

>> No.23209546

>>23195421
The oracle problem is bigger than just sending an API call to an isolated state machine like Ethereum. The oracle problem is the natural extension of consensus protocols: we have consensus on UTXO-based Bitcoin, then consensus on account-based Ethereum with its state + evm, and now chainlink is developing consensus on any arbitrary real world event that happens, possibly including even events on Ethereum itself to data consumers outside of it. The oracle problem isn’t about APIs, you brain dead mong. That’s the current practical use case for oracles, but it ushers in entirely new uses as technology and incentivizer mechanisms continue to develop and be tested.

>> No.23209823

>>23208428
Data is data, and it doesn’t predict anything. Models make predictions. You’re dumb.

>> No.23210122

>>23208908
>Having varied price sources is a benefit because it doesn’t rely on one data source to fuck everything up.
I completely agree - this is a huge benefit to the network. However this does not occur and cannot occur, because is no incentive for individual nodes to provide unique price sources - indeed they get punished for it. The end result is what you currently have - paying 20 nodes for price feeds, but they all use the same 2-3 sources, so in the end the network is worthless because even if the 20 nodes are "decentralised", they're all using the same centralised source anyway. You might as well plug the api directly into etherscan and save the exorbitant amount of money it costs to get prices, because that's where you'e getting them from anyway.

>> No.23210214

>>23208563
Not a bad line of thinking

>> No.23210219
File: 46 KB, 538x680, 1602259954912.jpg [View same] [iqdb] [saucenao] [google]
23210219

>ITT: a fundamental "misunderstanding" by OP of the staking incentives and guarantees
Where is staking in API3's little scheme OP? Imagine an API provider taking the risk of losing a stake because it fucked up something on a blockchain.

>>23206707
>I know one of them personally, and i dont have anything positive to say
Kek

>> No.23210225

>>23208908
Again, if this were the case, the price feed distributions would look like a normal distribution. See:>>23196690

>> No.23210239

>>23209361
>Do you know what a weighted average is
How would you do a weighted average in this context?

>> No.23210250

>>23209432
>medianizer is for Sybil resistance, not for a statistically robust price analysis
not following unfortunately

>> No.23210265

>>23209546
>and now chainlink is developing consensus on any arbitrary real world event that happens
The difference between this and the previous two things you list, is that the lattermost is ill-defined.

>> No.23210297

>>23210219
>a fundamental "misunderstanding" by OP of the staking incentives and guarantees
Staking implies that penalized nodes (outliers) are poor-performing nodes. What if outliers are better-performing nodes?
>This creates something of a Schelling point around cheap and easily available data. Further, this makes staking difficult, if not impossible, in such systems because now high-quality, curated data sources become outliers. (Issues regarding staking in such systems will be covered in more detail in a later post in this series.)

>> No.23210350

>>23210297
you didn't answer my question faggot. Where is staking in API3's little scheme? What prevents failure in contracts that secure billions of USD?

>> No.23210358
File: 106 KB, 927x806, A4D52F0A-BCB6-49C6-8E5B-34D4C00F5CFD.jpg [View same] [iqdb] [saucenao] [google]
23210358

>>23206570
So how does your aggregation contract differ?

>> No.23210409

>>23210122
How do they get punished for it? Give me one instance where a node operator was punished for using a unique source. One. I’ll wait

>> No.23210419

>>23210350
Quantifiable Security through Insurance. Further, in general, API providers have less incentive to provide faulty data since they have an off-chain reputation to maintain. Further, I think you might be over-estimating staking's effectiveness in a system that implements some form of consensus on continuous data instead of discrete data.

>> No.23210434

>>23210409
Current price feeds are highly centralized in that node operators are explicitly told which data providers to use.

>> No.23210451

>>23210409
>>23210434
The game theoretic argument applies to a decentralized system.

>> No.23210541

>>23210225
I’m just curious, but are you trolling or is your team really this dumb? Is it the language barrier? Normal distribution huh, why that exactly? Why not a chi distribution? Why do you even assume your rudimentary analysis of a 10 node sample size is enough of a sample to even discern what probability distribution you’re looking at anyway? Why don’t you collapse all of those data into one plot, first normalizing each, then look at the distribution?

>>23210239
>how to use weighted average to favor more expensive data
Gee, I really wonder. How could I give more weight to api calls with higher price tags?

>>23210250
Kek. How do you not follow? Aggregation is about reliability and security. Multiple nodes means you can’t manipulate a single data source, and using the median value of the response guarantees that an attacker must buy a majority of operators to alter the price feed significantly. Do you understand math at all, like median values?

>>23210265
Even if it is ill-defined, reframing a necessarily vague problem (because of its scope and only being possible to contemplate because of the paradigm of immutable, reliable consensus) into an oversimplified authenticated api problem is an unethical money grab at best, concerted vampire attack at worst.

>> No.23210567

>>23210434
Really? I thought there was a lack of transparency, so how exactly do you know what node operators are told to use?

>> No.23210595

>>23210419
>muh insurance
>muh off chain reputation
So, it’s basically the same as chainlinks current form: operators have to maintain an off chain reputation, PLUS some undefined, externally provided insurance. So who provides the insurance for your nodes?

>> No.23210597
File: 54 KB, 512x512, 1.png [View same] [iqdb] [saucenao] [google]
23210597

>>23210419
>Quantifiable Security through Insurance.
INSURANCE? I'm sure the API providers will just LOVE having to pay some third, centralized party for insurance, rather than being paid by an oracle.
HAHAHAHAHAHAHA

What insane insurance company will back an API that might just take a bribe to fuck up some billion dollar smart contract in someone's favor? Holy shit.

>> No.23210621

>>23210451
You’re applying the idealistic decentralized game theory flaws to aggregation contracts that are live today, which aren’t decentralized, and which aren’t the contracts that will be used for staking or for consensus with NEET nodes.

>> No.23210657
File: 846 KB, 993x738, 10yrold.png [View same] [iqdb] [saucenao] [google]
23210657

>>23196152
Holy fuck look at this utter retard.
Hans, wake the fuck up.

>> No.23210705

>>23210597
Not only that, but they’ll be covering nodes that are all deployed in AWS as serverless lambda functions, so there’s a very real possibility that an attacker ddos’ing a cloud endpoint could take down several other apis simultaneously. It’s not like Amazon has EVER had widespread downtime, either. Definitely wouldn’t be an issue if ever node was a serverless function.

The fucking balls of this team. Do you guys fucking think you can piece together some hack job better than Ari Juels can design you into obsoletion? Or is this an actual, deliberate scam?

>> No.23210712

>>23210541
>Normal distribution huh, why that exactly?
Because if nodes really do approach the same value, you'd expect to see response distributions centered around that value.

>How could I give more weight to api calls with higher price tags?
You would have to trust api call prices to be reported truthfully. It's also not a perfect measure of quality.

>Multiple nodes means you can’t manipulate a single data source
What if all nodes gather data from the same data source?

>reframing a necessarily vague problem into an oversimplified authenticated api problem
It's not an equivalence. The API Connectivity Problem does not, for example, claim to solve getting data from subjective sources onto the blockchain, which is arguably a subset of the Oracle Problem. It claims that *if* certain data types are already served by API Providers, you are better getting that data from them rather than a multitude of middlemen.

Thanks for your response.

>> No.23210714

>>23195421
>blatantly ignores short-mid term solutions for the Chainlink centralized architecture
>rants for an entire blogpost about potential solutions that will be obsolete once automated service agreements come into play
Okay

>> No.23210738

>>23195421

Man-in-the-middle paid data broker is just a definition of a scam.

fucking imbeciles lmao

/thread

>> No.23210739
File: 276 KB, 2289x2289, chadwojak.jpg [View same] [iqdb] [saucenao] [google]
23210739

Someone tl:dr me why the Stinkies itt are acting so defensive and butthurt? I'm not going to read the whole thing, but it something gets the Marines (:D) this on edge, then it must be good and I will support it.

>> No.23210749
File: 389 KB, 1200x900, 1561518121847.jpg [View same] [iqdb] [saucenao] [google]
23210749

>>23210739

>> No.23210759

>>23210739
I don't know, I didn't read the thread and I'm not selling

>> No.23210850

>>23210712
Why would I expect the value they approach to be centered? Why not left shifted? Give me a math proof.

>the oracle problem has an oracle problem
kek. I agree it’s not a perfect measurement of quality, which is why I don’t understand your point about cheap APIs being favored. Are expensive APIs better?

>what if all nodes gather from the same data source?
>what if all Ethereum nodes computed the same change of state as each other? Why not just use one Ethereum node then?
Listen, retard. Same source nodes just adds redundancy to your calls. What if one node goes down? Now your contract just had a failure. So you pay 3, 4, 10, etc. nodes to ensure uptime.

You’re putting the cart before the horse, right now api companies don’t serve blockchain directly and would have to manipulate their infrastructure to make that happen. Sergey&co took the 9000IQ route and said ok, we’ll consume your data for now, but you can sell it directly if you want. Until then, we’ll just connect it all. But YOU want to ask every single API company to deploy an aws node, because you think saving money is all they care about.

>The Oracle Problem
What happened to the “fake air-quotes”? I know it’s not an equivalence, that’s my point. Now it’s a subset? I’m saying it’s an oversimplistic reduction, which you’re touting as an equivalence, falsely.

>> No.23210868

>>23210739
>this is your brain on cooming

>> No.23210896

>>23196265
they may are but chainlink already knows this and working on solutions
it’s not like any other product solves this
>>23195779
also this stupid
it may or may not be multiple sources
but that’s not a problem of link itself

>> No.23210930

>>23210712
>*if* certain data types are already served by API Providers, you are better getting that data from them rather than a multitude of middlemen
Delivered by aws doesn’t mean you removed the middlemen. You’re taking all of that cloud infrastructure for granted. It also doesn’t stop you from using your governance to collect fees on each call in two years if your system ever makes it past your shitty github. You don’t have a way of giving API companies payments in USD, do you? The fucking irony of chainlink making that possible is hard to ignore. So are you going to give these API companies accounting software to accompany their new income stream, paid in a volatile asset?

>> No.23211036

Your entire experiment can be obliterated in one chainlink blog post.

>> No.23211061

I'm not reading your string of quotes for this boring article. If you have a point to make, make it.

>> No.23211092
File: 1.70 MB, 4128x2300, 42 (26).jpg [View same] [iqdb] [saucenao] [google]
23211092

>>23211061

>> No.23211112
File: 42 KB, 640x640, 1ffe8bb1.jpg [View same] [iqdb] [saucenao] [google]
23211112

SO WHAT THIS THREAD MEANS TO MY 500 LINKIES

should i sell?

explain like im five

>> No.23211174

>>23195435
This is actually a fine point I overlooked. Oracles unironically are the source of truth, and here’s why.

>the correspondence theory of truth
Truth in this sense is only guaranteed in the context of a statement about a real world event. True means that the statement corresponds to what really happened in real life, false means that the statement did not happen in real life. In the case of an oracle, we have real life (some api data), and we have a statement (the oracle fulfillment), which means that ONLY the oracles statement can be true or false and not the data itself.

By combining source and oracle, you’re effectively passing the responsibility of truthful reporting as an oracle to the data source. Now, your API providers can be directly responsible for when a million dollar contract gets hacked from a flash loan price manipulated event.

>> No.23211187
File: 1.07 MB, 2880x1953, 42 (22).jpg [View same] [iqdb] [saucenao] [google]
23211187

>>23211174

>> No.23211368

>>23211187
>didn’t listen, not selling

>> No.23212623

>>23204256
and now you answered why everybody will just use chainlink. thank you.

>> No.23212706

>>23206570
XD

>> No.23212871

>>23211036
Actually Chainlink did this to themselves with their last one. It showed a feed architecture based on first party oracles, with no third party nodes, strange it appears after the API3 white paper. Also means they dgaf about all the other benefits of third party nodes. Muh oracles are a source of truth fucking lol hey Siri what is a sybil attack

>> No.23213067

>>23210597
>>23210705

fckin this

>> No.23213451

>>23210930
>Airnodes only use aws
The team have said they'll be able to be deployed on whatever cloud provider the API uses, so if the cloud was ddosed then the API would go down anyway. At that point you could have a billion nodes serving it and they'd still return null.
>muh nodes

>> No.23213594
File: 369 KB, 1600x1363, D77BB6C8-0B73-40FD-90AC-9FFDC28CA449.png [View same] [iqdb] [saucenao] [google]
23213594

https://blog.chain.link/sell-your-apis-and-data-to-any-blockchain-using-chainlink
refute this blog post and tell me what you do different from pic related

>> No.23214669

>>23213594
API3 does the "Advanced" one but with an oracle design that's more reliable and maintenance free, with cheaper gas fees thanks to xDai, quantified security through the insurance pot and trustless governance.

>> No.23214690

>>23206570
Good argument. Thanks. Any counters, lads?