Attention Stinky Linkies. Reminder that Witnet will have algorithmic reputation

Wait a minute there nolinker, you're telling me that

>despite hating LINK you monitor the price religiously and make a thread as soon as there is any movement
>develop novel and intiutive FUD plotlines using the most up to date information you constantly seek out
>dedicate your creative energies to editing maymays with LINK branding
>have LINKtrader, GitHub, Gitter, pivotaltracker bookmarked so you can keep up to date with the project you hate
>actively participate in a LINK discord or telegram group
>know more about LINK than any other project, even more than stinkylinkies themselves

You need to have sex my dude

I'm not a nolinker and I don't hate link. I'm just trying to bring linkies down to earth.

Reminder that I'm never fucking selling

>i have anons well being in mind
have sex incel

See

Imagine shilling Borat coin kek

Attached: 770FC23E-DEBB-4760-8761-62A554213E2F.jpg (440x501, 182K)

>Not cost effective enough
Nobody has any clue about the cost of Chainlink at full function.
Especially with solutions like threshold signatures right around the corner.

You are a grade A bullshitter.

I do need to have sex
>With Chainlink you can use any reputation contract you want and can build them yourself.
Read the fucking white paper.
No one who wants data via oracles cares about neet reputation provider / node listing services when they can just use nodes listed by trusted reputation providers. The big win. People trust what other people trust.
You should sell, but only in 4-10 years. There is a more efficient and less error prone way of inputting data from APIs to smart contracts than semi-decentralized oracle networks, but no one is currently making it and there would be no way API owners would even think to adopt it until they let chainlink get their middleman cut for several years and think about how they could go around this and get higher API call margins from the smart contract data call market.

>No one who wants data via oracles cares about neet reputation provider / node listing services when they can just use nodes listed by trusted reputation providers. The big win. People trust what other people trust.
What in the world are you babbling about.
Regardless of any other variable, the reputation contract can be anything you want.
It says so right in the white paper.

You don't even understand what treshold signatures are and you have no concept of how chainlink would supposedly run smart cities and IOT. Chainlink is a solution to another problem. Treshold signatures could concievably be used to run a type of 2nd layer scaling solution for microtransactions, but it would not be anywhere near as efficient as a dedicated 2nd layer scaling solution with dedicated operators. One could conceivably make it somewhat not as horribly behind in efficiency via some kinds of aggregation (I'm not talking about treshold signatures), but that would introduce latency. That's a no-no.
Yes, you can make your own reputation system that has its own list of nodes and you can automate it. You can even copypaste witnet's. No one is going to use it when they use chainlink, however, and by extension the nodes that have reputation through it, because there are more trusted reputation sources. Sources approved by the chainlink project leaders themselves or sources (reputation providers / node lists) made by trusted entities in traditional finance.

>You don't even understand what treshold signatures are and you have no concept of how chainlink would supposedly run smart cities and IOT. Chainlink is a solution to another problem. Treshold signatures could concievably be used to run a type of 2nd layer scaling solution for microtransactions, but it would not be anywhere near as efficient as a dedicated 2nd layer scaling solution with dedicated operators. One could conceivably make it somewhat not as horribly behind in efficiency via some kinds of aggregation (I'm not talking about treshold signatures), but that would introduce latency. That's a no-no.
blablablablablablablablablablablablablablablablablablablablablablablablablablablablablablablablablablablablablablablablablablablablablablablablablablablablablablablablablablablablablablablabla

Nobody (least of all the Chainlink team themselves) have ANY idea about the actual cost of Chainlink when fully operational.

You are a massive bullshitter.

>Yes, you can make your own reputation system
Good on you for admitting your mistake.

Well stated. No real business is doing business with companies that don't complete due diligence on employees or subcontractors they work with. Anybody that believes otherwise doesn't have a clue.

>Nobody (least of all the Chainlink team themselves) have ANY idea about the actual cost of Chainlink when fully operational.
That's bullshit. You can know from the structure of the system what it can't be efficient for what it might be efficient for. Of course no one knows EXACTLY how much every kind of data call will cost, even if one pretends the gas cost on the host chain of the calling smart contract doesn't exist, but one can guesstimate a range for the cost of running a node, the cost of the node's API calls and the cost of capital for staking.

If you don't think the chainlink team and everyone they work with that plan to run and to use chainlink oracles have estimations on that, you're not thinking this well enough through.

>Good on you for admitting your mistake.
It wasn't a mistake. Those reputation providers are worthless. I explained why multiple times. Nodes that use them won't get jobs.

>That's bullshit.
No it is not.

NOBODY knows what the actual cost of Chainlink will be when it's operational.
Especially with things like threshold signatures which can group anything from two to thousands of transactions.

>It wasn't a mistake
Except it was.
You literally said in the OP "Witnet will have algorithmic reputation (...) unlike in chainlink".

Keep bullshitting for all to see.

Okay, nitpick if you want to. The point was that you can't run neet nodes with chainlink and expect to get jobs. The reason for that is that you effectively can't use non-KYC non-high-standards reputation providers and expect to get jobs on chainlink.

So sure, you can technically use an algorithmic reputation provider for your chainlink neet nodes. You won't get any jobs. You can't run neet nodes and get returns.

On witnet you can.

>No it is not.
You're being facetious now. You're not that deluded.
>Especially with things like threshold signatures which can group anything from two to thousands of transactions.
That's not what treshold signatures do. Reread the blogpost. Don't listen to Timo. He is maximally deluded. Ask Coventry if you want.

>nitpick
This isn't nitpicking.
You're pulling bullshit claims out of your ass.

>So sure, you can technically use an algorithmic reputation provider for your chainlink neet nodes. You won't get any jobs.
>You can't run neet nodes and get returns.
>On witnet you can.
Why can't you on Chainlink, but can you on Witnet?

>That's not what treshold signatures do.
That's literally what they do.
Literally from the white paper:
"The benefit of this approach is that for a given query, a single signature can be generated off-chain by a collection of n oracle nodes. As a result, only a single authenticated message needs to be handled on-chain, instead of O(n) messages from distinct oracle nodes"

Keep blowing it out your ass.

Yeah, I don't get why people think threshold signatures will somehow fix ethereums scaling issues. Doesn't it just collate responses for a single query?

>Doesn't it just collate responses for a single query?
Instead of potentially thousands of messages being posted on-chain, only a single one is.
If you don't see how this helps fix scaling, then sorry about your brain.

It helps, but does it do anything for unique queries and transactions? If ethereum were to see numbers of users , how would threshold signatures work?

>You need some in-group schmuch (((reputation provider))) to decide that you are upstanding citizen
Fine by me, I'll get one of my discord tranny bros to help me out

>but does it do anything for unique queries and transactions?
Instead of potentially thousands of unique queries, messages, and transactions, only a single one is posted on-chain.

Wrong. If you don't understand the blog, ask the team themselves. Ask Coventry. Don't listen to deluded fools like Timo.

Again, literally from the white paper:
>The benefit of this approach is that for a given query, a single signature can be generated off-chain by a collection of n oracle nodes.
>As a result, only a single authenticated message needs to be handled on-chain, instead of O(n) messages from distinct oracle nodes
>The idea can be further extended, as in [30], to aggregate the answers to multiple queries within a single threshold signature

You absolute retard.

Sergey purposely instituted kyc as a fuck you for all the memes so hopefully /biz neets can fuck off from the project.

KYC is optional, so your bs doesn't even make sense.

The key phrase is "for a single query".
When you stop ignoring that, you will understand.

What you quote literally said it is what me and says it is.

excuse me, "for a given query".

>The key phrase is "for a single query".
>for a given query
That's why it says "The idea can be further extended, as in [30], to aggregate the answers to MULTIPLE QUERIES within a single threshold signature" literally two lines down.

fucking lmao

And even if you ignore this, the fact would still remain that potentially thousands of signatures can be collected off-chain, and then submitted as a single signature on-chain.

If they get it to work, it will still only scale responses to data calls from smart contracts.

It will not scale data calls themselves.
It will not scale payments to link nodes in link.

Here comes the damage control.

>it will still only scale responses to data calls from smart contracts
Yes, i.e. the very backbone of ETH can be largely offloaded off-chain.

>It will not scale data calls themselves.
Haha what?
"Data calls" are inherently off-chain. Everything that has to do with oracles literally sits between the data and the underlying blockchain.
Various different data calls can be handled, processed, given consensus, ... all in a single on-chain signature.

Are you having a stroke?

>It will not scale payments to link nodes in link.
Of course it will.
Payments for individual nodes or even collective nodes can be aggregated over a certain period.

>Yes, i.e. the very backbone of ETH can be largely offloaded off-chain.
No. You misunderstand. It only aggregates answers.

>Payments for individual nodes or even collective nodes can be aggregated over a certain period.
Yes, but not via treshold signatures. A suitable 2nd layer scaling solution is necessary to handle that.

>No. You misunderstand. It only aggregates answers.
And queries.
Which is exactly what any consensus mechanism does.

You're probably having a stroke.
No other way to explain this level of absolute retardation.

>Yes, but not via treshold signatures.
Yes via threshold signatures you absolute moron.
Any token payment goes through smart contracts.

What a fucking brainlet. Thanks for buying my bags!

>And queries.
No.
>Yes via threshold signatures you absolute moron.
No.
>Any token payment goes through smart contracts.
Irrelevant. The payment aggregation is not through treshold signatues. It is possible to devise a system for payment aggregation that relies on using a set of chainlink nodes for validation, operating with treshold signatures as a trigger for withdrawal of aggregated payments, but it would require an additional system or specialized nodes to keep track of off-chain state. It's inefficient and impractical compared to scaling payments with a 2nd layer that relies on dedicated operator(s) that keep track of state and can have various other guarantees baked in like liveness guarantee / data availability guarantee watcher nodes that can help exit in case of failure.

You don't understand.

>No.
"The idea can be further extended, as in [30], to aggregate the answers to MULTIPLE QUERIES within a single threshold signature"
Literally from the white paper.

You're just lusting after that ass reaming, huh?

>The payment aggregation is not through treshold signatues.
Yes it is.

>it would require an additional system or specialized nodes to keep track of off-chain state
>t's inefficient and impractical compared to scaling payments with a 2nd layer that relies on dedicated operator(s) that keep track of state
Are you trying to tell us on-chain "operator(s)" can keep track of "off-chain state"?
Do elaborate!

>"The idea can be further extended, as in [30], to aggregate the answers to MULTIPLE QUERIES within a single threshold signature"
Literally from the white paper.
Answers to queries. Not queries themselves. Please read properly.
>Yes it is.
No. Do you think the chainlink team is buddy buddy and talks so much with 2nd layer scaling solution because they're useless to them? Sergey knows he needs an appropriate way to scale payments to nodes.
>Are you trying to tell us on-chain "operator(s)" can keep track of "off-chain state"?
No. I'm saying someone has to keep track of off-chain state (balances of payments aggregated) if a 2nd were to be run via a hypothetical validation system made up of chainlink nodes that use treshold signatures to allow exits. I'm also saying this is all pointless because it's inefficient compared to other proposed 2nd layer scaling solutions. You won't see treshold signatures involved with scaling/aggregating payments in LINK to nodes.

Seriously just go on the chainlink discord and ask Coventry. He is very polite and patient and will explain things to you. You will not accept anything else than someone with authority telling you what's what.

>hurrrrr node payments have to be on-chain and can't be handled off-chain (e.g. with threshold signatures)

Literally from the whitepaper:
"Our longer-term proposal is reflected in the rather more complicated protocol OCA (Off-Chain Aggregation) (...) OCA is an off-chain aggregation protocol that minimizes on-chain transaction costs. That protocol also includes payment to oracle nodes"

And a bit further is the literal proof that they're using threshold/Schnorr signatures for this OCA:
"Before presenting OCA, we give some basic background on Schnorr signatures and the threshold scheme for computing them"

In other words: Chainlink are LITERALLY going to handle node payments through threshold signatures.

L I T E R A L L Y

This is just savage.

Okay I read that section of the white paper. Basically they're doing a variant of what I said was possible earlier but I thought they would never do because it is inefficient. It's more efficient than simply leaving things on-chain, but far less efficient than using an appropriate 2nd layer.

If they're actually doing that to scale payments, it's a bad idea, though the white paper says its just an initial solution, so I assume the reason why they are buddying up with 2nd layer scaling solutions that claim to be general state capable is because they know it is inefficient compared to piggybacking on a dedicated 2nd layer scaling solution.

For the long term, they would not use a set of chainlink nodes & treshold signatures, because they are inefficient. It's unlikely that they will even bother to finish such a system instead of waiting for a decent 2nd layer.

>far less efficient than using an appropriate 2nd layer
Okay, user.
I'm sure you know better than the people behind Chainlink, including white paper co-author Ari Juels.

You said threshold signatures "will not scale payments to link nodes".
The white paper completely and utterly contradicts that.

You are an idiot with a massive case of Dunning-Kruger.

>I'm sure you know better than the people behind Chainlink
... go ask them. Their ideal way of scaling link payments is piggybacking on an appropriate 2nd layer.
>You said threshold signatures "will not scale payments to link nodes".
It won't because they won't use it because it's not going to be the best option by the time it could be done that way. Chainlink as a network would need to be much more expanded, with more nodes, and they'd have to have specialized nodes that handle state, and they'd also need to write the goddamn contract for this. None of that is done and it won't be done before there is a suitable 2nd layer available.
>The white paper completely and utterly contradicts that.
Yes, but you should read the context in the paper. It was never regarded as the ideal solution. The paper was written back when 2nd layer research was in its infancy and even then they understood that using that method of scaling payments via chainlink was inefficient and would only serve as an, as they wrote "initial" solution to the payment aggregation problem.
>You are an idiot with a massive case of Dunning-Kruger.
Ironic, considering you don't understand what we're talking about. You're probably just assuming I'm spouting nonsense so there's no point in understanding everything I'm saying.

Seriously, go on discord or slack and ask a knowledgeable person from the chainlink team. Go do it. I have seen them address this.

>Their ideal way of scaling link payments is piggybacking on an appropriate 2nd layer.
>It won't
Except the ultimate final solution for (among others) node payments revolves around threshold signatures, OCA.

I just literally quoted you the white paper, and still you cannot cope.
Get yourself checked into a mental hospital.

>Except the ultimate final solution for (among others) node payments revolves around threshold signatures, OCA.
No, it's inefficient. God.
I'm done. Go ask the team. They will tell you it is less efficient than a 2nd layer. Just do it.

>No, it's inefficient.
Yes, I'm sure you know better than whatever dumbasses wrote the Chainlink white paper, am I right?

Your responses get longer and more flustered as you get more btfo, lol

>None of that is done and it won't be done before there is a suitable 2nd layer available.
>reeeeeee

Keep going, dig deeper, you can do it

*Than a general 2nd layer. Considering one that relies on chainlink nodes and treshold signatures is a 2nd layer. Just not ideally efficient.

>Yes, I'm sure you know better than whatever dumbasses wrote the Chainlink white paper, am I right?
They only proposed it as an efficiency upgrade over on-chain payments on ethereum, which it is. I already said this. Retard.

>They're "only" doing the opposite of what I claimed!
Yes they are.

>They only proposed it as an efficiency upgrade
>They will tell you it is less efficient than a 2nd layer.
>Their ideal way of scaling link payments is piggybacking on an appropriate 2nd layer.

They clearly say in the whitepaper that OCA is their complete and long-term protocol.
It's basically what they see as the very backbone for Chainlink when running at full capacity, meant to handle everything from node response aggregation to payments in Link tokens.
Virtually anything Link will do, will have the ability to go through threshold signatures.

You're not coping well.