Today Zack pointed out some problems related to the Witnet protocol which we feel in the need to answer.
The first thing we would like to say is that we always appreciate the concerns and improvements highlighted by members of the community, specially if formulated in a constructive manner.
Witnet is adapting to new challenges and concerns pointed out by the community. As such, the protocol has noticeably evolved with respect to the original whitepaper proposal. We hope the following points address some of the concerns raised by Zack today.
"Witnet is a new blockchain specialized in oracles. They use a proof of stake consensus mechanism for block creation"
We would not call Witnet a Proof of Stake algorithm. Instead, miners/witnesses are selected based on past behavior through cryptographic sortition. As such, one can not say that users need to stake money to have better chances of becoming elected. Instead, users that have proven to behave honestly have higher chances of getting elected for committees/block mining.
"Witnet is a copy of Bitcoin Hivemind's oracle, similar to Augur"
We are happy to say that Bitcoin Hivemind (as well as other projects) has greatly influenced the Witnet protocol, but that does not mean it is a copy of it. Reducing the Witnet protocol to being just a copy of Truthcoin means the whitepaper and the documentation have not been completely understood. Indeed, Witnet's reputation system has little to do with that implemented by Bitcoin Hivemind. In fact, Witnet's reputation system is already implemented and running live on our Testnet-3. The code and documentation are available here.
"it uses random sampling to select around 2-6 voters to determine the outcome of your oracle."
Witnet lets the data request creator decide how many nodes fulfill the data request, for the moment, without any upper limit. The paper indeed mentions that hiring 6 nodes could offer an acceptable trade-off between security and cost, but that is offered just as an example. Every single use case has different requirements and the correct number of witness nodes needs to be assessed on a request basis.
"Witnet is assuming that it is impossible to bribe the oracle voters, and they don't provide any mechanism to explain how this could be possible."
The sentence is a particularly unfortunate claim from the Witnet whitepaper. It is true, as Zack mentions, that there is not a specific mechanism that prevents a witness from voting for the answer specified by a briber and get the rewards afterwards. However, we have continuously improved the Witnet protocol from what we outlined in the whitepaper, and we have implemented several mechanisms that will deter bribing acts, e.g., collateral. In the near future we will be publishing a more extensive report on how these mechanisms help securing Witnet.
"The problem of trusting a single api. [...] They could purposefully send the wrong data to the Witnet nodes, so that they will all provide the wrong data to the Witnet blockchain, and in this way, the people running the football results API can steal from people who are using Witnet to gamble on the result of the football game."
This is a mistaken statement about the Witnet protocol. One of the strengths of Witnet is that it allows the requester to specify several sources from which the data will be gathered, and most importantly, how they will be retrieved, filtered out, aggregated and agreed upon. Thus, even if one of the APIs is faulty or malicious, the final result will not necessarily be affected. In particular, the data request creator can provide specific scripts for defining how data will be processed through every each of the following stages:
- Retrieve: how the data point is retrieved from each particular source.
- Aggregate: how the data points retrieved from several sources are aggregated together.
- Consensus: how the aggregated results reported by each of the witnesses are agreed upon into a single result.
We hope these answers clarify some of the concerns raised by Zack. We are happy to see that Witnet is drawing a lot of attention, and in consequence, we will keep improving our communication over the next weeks and months. In particular, we may publish a new version of the whitepaper.