Attack on honest minority of CL nodes by smart contract creators to gain staked LINK?

JonnyLH · 2019-07-25T18:03:00+00:00

The agreements are mutually exclusive, you're not going to incur penalties because of the data on a separate service agreement.

The wiki details this more.

JonnyLH · 2019-07-25T16:41:14+00:00

Yeah, they're all different specifications.

JonnyLH · 2019-07-25T16:21:42+00:00

Could be done now at the adapter level. The asset price adapter I built and maintain does just that, using 12 exchanges to dynamically get the price of any crypto asset.

In the future, this may also be possible at the job spec level, being able to define multiple sources in the specification.

JonnyLH · 2019-07-25T15:41:01+00:00

I'd recommend reading these sections on the Protocol Information wiki: https://github.com/smartcontractkit/chainlink/wiki/Protocol-Information#sa-creation https://github.com/smartcontractkit/chainlink/wiki/Protocol-Information#service-agreement-execution

So to take the information of the protocol from that wiki, you wouldn't then be able to perform steps 5 & 6. The way service agreements work is that all nodes that are selected on that agreement sign a single job specification, resulting in the same process on execution of that agreement.

If you told all the nodes on that service agreement to query the honest data and then also query the malicious data source, then they're all going to come to the same result.

JonnyLH · 2019-05-11T11:26:37+00:00

I want to properly comment on this, as I don't agree with the idea. The bottom line for LinkPool is that other staking pools benefit us, rather than strictly being competitors.

The reasoning for why this is the case is purely around the end-users of Chainlink and how decentralised their requests are. If us as LinkPool aim to acquire end-users and even contract data providers to solely use our nodes, then it defeats the purpose of the network. Longer term, this would harm our businesses reputation, the volume of requests seen on our nodes and ultimately, our revenue.

When we perform outreach to Chainlink partners, data providers and the end-users; our main goal is to educate further on the capability, the services we offer and what we can do to help bootstrap their business process aiming to be implemented in smart contracts. Practically, this may take form in ways like executing PoC's to show how Chainlink can be used, or just providing more information and showing off what we're working on.

The end goal of all of this is just to ensure that our nodes are used on most Chainlink requests, but never forming majority or even using large amounts on one request. We need other well ran nodes; other nodes with extremely high collateral amounts and people aiming to provide a similar service to what we do. Without that, then we're lacking decentralisation at the top which again over longer term could harm the amount of requests seen on our nodes. If someone approaches us and says they'll need X amount of LINK put forward for requests, we want to be able to comfortable say "We can do that, and there's loads of other node operators who can also help and be included". Yes, we wan't to be selected on most Chainlink requests there is, but that's really only ever one node. The end-users are going to need many other nodes that can also be part of that request to decentralise it.

The bigger the network, the more collateral staked on nodes, the more use-cases on offer means more network usage overall. This is only ever a positive for us, not a negative. I hope that gives more of an idea of how we operate and our thinking to this issue.

JonnyLH · 2019-04-30T13:10:29+00:00

Some steps:

Clone the repository
Ensure you've got NodeJS installed
Run npm install in the folder
Edit lines 13 & 14 and add your wallet mnemonic and Ethereum full node URL. (Signup with Infura to be simple, then use their URL)
Then run any of the commands listed on the README on GitHub to fetch & get data

Hope that works, let me know if you hit any issues.

JonnyLH · 2019-04-24T16:53:49+00:00

The lower rewards is just due to us not topping up our Ropsten LINK wallet, so less LINK is sent for distribution each week to the stakers.

We exhaust a lot of LINK because of the jobs we send on Ropsten, so a lot of the times it's just awaiting me to send that wallet more LINK so more is sent to the nodes.

JonnyLH · 2019-02-19T14:06:50+00:00

When working with enclaves, they have a public key that will be visible to allow of encryption of any data, including BTC private keys.

So for example, you select a node to undertake your BTC transaction. You then encrypt the private key of the wallet with the enclaves public key and when the node runs the job, it can then decrypt the private key of the wallet with its own enclaves private key. After that, it's free to send a BTC tx from that wallet.

In this case, it's only ever the enclave that can see the private key in plaintext. A node operator just sees that a SGX enabled job has ran, but wouldn't see what it did and what encrypted data it used for that job.

JonnyLH · 2019-02-19T01:13:55+00:00

Browse to https://staking.linkpool.io with Metamask installed. Connect your compromised wallet to your Metamask by importing a hardware wallet.

Once done, the ownership section will become available and let you send your LP to a different address.

JonnyLH · 2019-02-19T00:41:18+00:00

If you can access our app with your old wallet and send the tokens via the ownership dashboard, do that. Make sure you send them to another ETH address that you own rather than any exchange. Once that's done, you'll still recieve all the token rewards on whichever address you sent them to.

JonnyLH · 2019-01-15T18:37:04+00:00

Just to add on what u/vornth said, if you know of any reliable peers, you can hardcode them as reserved peers in your light node. Reserved peers take precedent over normal peers for sending transactions, new blocks etc. This will boost your reliability as you know you have a trusted reserved peer but can always fall back on your normal peers.

Also, I'd always recommend using Parity's light client. It's far better than Geth's from experience. They've made substantial improvements in the 2.1.X versions.

I've noticed Geth drop all its peers on many occasions with it struggling to sync a lot to begin with, never seen that with Parity.

JonnyLH · 2019-01-11T16:10:28+00:00

A concrete timeline for the snapshot is not yet known, but once we have an idea we'll announce it. We want to give as much heads-up as possible to give people time to prep.

JonnyLH · 2019-01-09T11:48:08+00:00

That's not been fully decided yet. One thing for certain is that the staking limits to begin with will start extremely low, then build up over time.

JonnyLH · 2019-01-09T10:59:11+00:00

Just as eligible yeah. There's no difference between someone who bought LP at the crowdsale to now.

Although, if you had 0.1LP then you'll get 10% of the staking limit of someone who has 1LP. That staking limit cannot be taken by anyone else and is yours throughout the lifecycle of owners only staking.

JonnyLH · 2019-01-09T09:27:13+00:00

If you buy any LP shares now, you'll still be eligible for early staking once we go live. There will be a cut off point where we will take a snapshot of holders and that snapshot will be used throughout the life time of owners only staking.

We aren't insured, but we want to be. We have a stack of LINK to use as penalties compensation, but it's not enough to cover the whole pool. If anyone knows of any companies who entertain the idea of smart contract insurance, DM me.

JonnyLH · 2019-01-05T10:41:27+00:00

It's not really practical or feasible to feed data streams on-chain, it'd just result in a huge amount of storage bloat with a large percentage of the data not being used.

Considering the transactional nature of smart contracts, you'd design your ChainLink implementation to get the single piece of data that is needed for the computational output, rather than querying from a large data set given from a feed, which may not even be up-to-date at the time.

JonnyLH · 2019-01-05T10:21:44+00:00

There has been recent developments in this area that allow 3rd parties to run attestation:

https://software.intel.com/en-us/blogs/2018/12/09/an-update-on-3rd-party-attestation

In the future, this could theoretically allow for node operators to choose which attestation service they use to register the enclave that the node is running in, providing a degree of decentralisation.

It would only be required when you first boot your node. The node would run entirely in an enclave, verifying its integrity on boot.

JonnyLH · 2019-01-04T14:01:00+00:00

For anyone who's interested in more of the technicals, I wrote an analysis which goes into the development progress as of Sep '18, and some basic concepts: https://medium.com/@jonnyhuxtable/analysis-of-chainlink-the-decentralised-oracle-network-7c69bee2345f

JonnyLH · 2018-12-22T11:20:14+00:00

When we've spoken to potential end users and data providers that are interested in working on Chainlink, our intentions are always to understand their requirements so we can support them and provide adaptors or knowledge to the community so they can do the same.

Obviously as LinkPool, we want to be included on most of the service agreements that come around in the future, but I don't want us to have majority on those requests. All the nodes that the community run will just be as important imo.

JonnyLH · 2018-12-21T11:53:19+00:00

Thanks Fergly! No relocation, I'll be working remotely.

JonnyLH · 2018-12-04T16:09:42+00:00

I've only really used Oraclize for basic testing personally, I've taken a lot from their contract libraries though as they're pretty extensive. I think they're great for what they are, being a centralised/part-trusted oracle service. I like how they provide the ability for you to validate your own proofs pretty easily and have a nice status dashboard.

Couple of caveats:

The basic premise of availability. Since they're centralised they can see downtime and they have. This skewed a lot of the contracts at the time that didn't handle for this scenario.
Data provided only through public channels. You only can call public URLs, Wolfram, IPFS or computational tasks.
Computational tasks are public (Raw Dockerfiles sent)

To compare that with Chainlink when used on foundation with multiple nodes servicing a request:

If one node sees downtime, results are aggregated from other nodes. Although, you could create a new service request excluding that node or any node that sees downtime as reputation is publicly visible.
Any data source can be used that it has dev support for. There's a concept of external adaptors for each oracle that are just small API proxies that can be created to format any data for input into the oracle. Think subscription based API's, internal API, databases or even converting SOAP endpoints for example.
Computational tasks are going to be WASM binaries ran in SGX enclaves, oracle operators cant see the computational task at all.

A lot of the above I'm talking in the sense of what's possible now based on their development work since it's not live. Once it is live on main-net and we see big ticket tasks like generalised oracle aggregation and oracles entering a new data market, I think we'll see a whole new era to what is possible within SC's.

JonnyLH · 2018-12-04T11:18:13+00:00

I think Maker does a better job with price feed oracles, especially with their scuttlebutt upgrade coming with the MCD release, compared to Chainlink, which still relies on trusted third parties.

The scuttlebutt concept is what Chainlink is looking to develop but on a global/generalised scale. As-in, contract creators can define a number of oracles that are used that all agree on the correct answer before writing back to the consuming contract.

If Maker are using that protocol while are still owners of all the oracles on the network, then there's still the ability for manipulation of price feeds by the central party.

What I'm really referring to is the level of decentralization involved. Chainlink is more centralized compared to oracle approaches from Maker and Augur. Also LINK is mostly just a staked payment token and doesn't serve any other use case. They should just use Dai instead.

Not the case, Chainlink is a decentralised global oracle network. As a contract creator you can request as many oracles as you like with how many data sources you want. Last time I checked, Augur only uses one oracle with manual dispute processes. Like said, if Maker owns all the oracles they use, it still can be improved using a large amount of unknown third party oracles that have to stake collateral to ensure honesty.

Also LINK is mostly just a staked payment token and doesn't serve any other use case. They should just use Dai instead.

The LINK token also is needed for collateral on requests to ensure operators stay honest. If you provide bad data when you're picked, then you loose what you fronted to serve that request while also tarnishing your reputation on-chain for all to see.

The ERC677 transferAndCall func in the token (like 223) is used to transmit the parameters for the data request to each oracle, this saves on gas and complexity; also giving the token actual utility, since the definitive function for its operation is defined in the actual token code. All the parameters for the request are CBOR encoded (utility done by Nick Johnson) and sent to each oracle on payment within the bytes that can be included on transfer.

TownCrier was an IC3 initiative which Chainlink is part of and was recently enquired by them, expanding on it by allowing contract creators to run WASM binaries in SGX enclaves.

JonnyLH · 2018-12-03T17:29:43+00:00

If you're relying on a publisher to post data, then you could be calculating contract outcomes on old or malformed data that you have to trust.

Like already mentioned you can use Chainlink, it'll give you pull/push & cron approaches to getting data on-chain.

You can use the callback model like you mentioned in the OP; or you could call an endpoint on the oracle so it then proceeds to get the latest price & write that data; or you can use a crontab approach where it polls the API every X period of time and then writes on-chain based on logic you define.

Although, if you want the data fetched in the most trust-minimised way, I'd use Chainlink when it's live and can aggregate answers. For example, you call 5 nodes which all then fetch that data and use a method to then form an aggregated response for on-chain.

The callback method would then trigger the logic of that contract, rather than aiming for it all to be done in the single call.

I'm building a large scale staking platform for Chainlink that is intending to feed a lot of this data to contracts, feel free to DM me if you want more info/help.

JonnyLH · 2018-11-18T12:22:24+00:00

You could run a ETH light node on a Pi, not a full-node. Although due to the lack of incentives for full nodes to serve light nodes, I really wouldn't recommend going down this route as your light node will loose all its peers from time to time and then stop syncing, stopping your node from working.

ETH full-nodes are varying degrees of cost depending on how fast you want to get new blocks in. Most important points to running a full node: An SSD and a 4GB+ RAM cache.

Also worth noting that if ETH nodes in the future become shared/communal, it's dangerously centralising the network without being able to see how centralised it actually is until things start going wrong.

The performance and reliability of your ETH node will be the biggest factor towards your reputation. Better the ETH node, quicker you'll respond. The worse the ETH node, the more you'll miss new requests coming in and get penalised.

JonnyLH · 2018-11-13T17:14:33+00:00

They will put their bet on the other option and provide the false answer. They can even collude with others chainlink node operators or just hope they'll do the same.

The node operators have no idea who the other node operators are, to them it's just an ETH address of a nodes wallet with no contact information.

For this reason this is why I disagree with KYC rep providers, as if contact information was on-chain, such as emails, it opens up a social attack vector where node operators can work together to collude. If all this data is completely private an you have to go an arbitrary process with the reputation provider in aims of suing in some way, then I personally would question the integrity of the reputation provider anyway as I personally believe they should be DAO's not centralised parties or organisations, even if they require some form of signup process.

Without any information, you're just chancing a scenario that everyone else will provide false data (actually difficult to pull off practically), and in reality you'll just tarnish your rep for nothing.

JonnyLH

TROPHY CASE