Let's talk about staking on Chainlink nodes

Let's talk about staking on Chainlink nodes.

I've read on here a number of times that people intend to *stake* their LINK, as if it's a black box where you input your LINK and it magically offers API data to smart contracts thus earning you a profit.

That may be the case for Linkpool staking, but if you don't want to give away 25% of LINK returns then you're essentially responsible for creating access to individual APIs on your own node.

So what APIs are you planning on offering? What hardware are you using to run a node? Do you have a dedicated machine or are you just running it from your PC?

I think that external adapters greatly expand the capability of the Chainlink nodes, and they can be written in any code that the Chainlink node can interact with so long as it passes data back in a format that can be digested by the smart contract once it's done with the off chain computations. These are also key to having a unique task that only your node can fulfill, thus guaranteeing that your node will be called by smart contracts.

Basically, if you're planning on staking LINK, and hoping that LINK is going to be a success, what are you doing to secure its usefulness once mainnet is launched? There's no fucking point in a mainnet if it has no data providers once it goes live.

Attached: 1516316887436.png (604x711, 368K)

Link is a scam user

Token not needed full stop

>Let's talk about staking on Chainlink nodes.
no, let's not. nobody is making money staking on chainlink, the only way chainlink works is when there are so many providers that the fees have been pushed down to effectively zero.

Cant wait for some competition for linkpool so youre not taxed 25% lmao

Look, I'm not here to argue with you inbred fucknuggets about the viability of Chainlink as a project/concept. I'm here to talk about running a Chainlink node. You can FUD all you want, and maybe the mouthbreathing retards that eat the crumbs of shit that fall out of your prolapsed anuses will fall for it, but I'm looking for the anons who actually intend to operate a node independently of a staking service like Linkpool.

I KNOW there's anons here who have spun up a Chainlink node given the instructions by Steve.

What are your plans for redundancy though? Like if your node goes down for some retarded reason like a net outage you can still get penalized right?

Attached: cummulatin.png (1024x768, 552K)

I feel like linkpool will be the only one I can trust though, don't want get bitconnected by some bullshit wannabe scam linkpool that promises the world but exits scams

That's a good question. If your node goes down during the time when a smart contract makes a data request, then I don't think there's really any way to mitigate that loss of collateral that can be controlled from the side of a node operator. It would have to be something implemented as part of the Chainlink infrastructure.

Even running multiple nodes seems like it's not a perfect solution, because smart contracts will be requesting specific nodes based on the ID of the node. So even if I had a second node at a different location, or N nodes distributed across a cloud services, the node that went down would still lose collateral despite the others feeding in the data. Also adding more nodes, with the requirement of collateral, would increase the total amount of LINK necessary to offer data to the smart contract, which would be more risky and expensive.

So I'm not sure what the best plan for redundancy is at this point in time, other than to say that's just the risk you take as a node operator offering API data. If your node goes down during a data call, then you're fucked.

To add to this:

The ideal solution, from the Chainlink side, would be for the smart contract to allow for a delay in the data in the event of a failed call, with a list of nodes to request in the event that the first one goes down. This is of course considering a unique scenario in which a node operator offers data/an offchain service that is exclusive to a single node provider and thus not available from other nodes (basically having proprietary/private external adapters, for example the SWIFT payment node). In this case, having three nodes in different locations would be good for redundancy, where the second and third nodes are only queried in the event that the first/second fail to return an API call.

Of course, this is again a really specific scenario, but as an independent node operator if you want to make money then you have to offer data/an offchain service that isn't available to the general public or that isn't trivial to code for an average learner.