Thanks! Good question. In one model, the issuer of the feed must pay 1 NFD every time he updates the feed, which should be automatic when he has enabled the feed and designated funds for it. This could be 1 time per day or 1 time per hour. Why would the feed issuer pay such fees??? Well... because he earns a percentage (e.g. 0.1%) of the bets made against the feed.
If a feed is temporarly unavailable, then the CFD is closed?
Yes. I would say that if it does not publish within X blocks/days of when it is supposed to, then the CFD is closed and everyones money is returned.
This could lead to many forks. As example, Chinese are not allowed to connect to certain networks.
The most problem I see are DOS/DDOS against the feed source.
The DDOS problem exists but I'm not sure if it is really an issue. The common case will be large sites like yahoo finance and google, which presumably can handle the load. I am not sure NDF or even NXT are big enough to pose a problem.
The only DDOS issue I can see is a synchronisation problem where all NFD peers verify the feed tx from a block at the same time and NFD forgers all try to validate newly encountered feed tx's at the same time.
Here's a solution to this problem.
1.. NFD forgers do not validate feed tx's unless they forge the block. This limits the number of forgers validating an unconfirmed feed tx to only a few per minute.
This would open a wide window for manipultions. The trust of the block chain depends on the fact that every node can verify transactions and blocks.
2.. NFD peers load spread feed tx validation by waiting a random number blocks over a 60 block window before performing the feed tx validation. Additionally peers do not consider feed tx's confirmed (nor do they act on them) until they have 120 confirmations.
In this solution NFD peers do not reject blocks with invalid feed tx's. If an invalid feed tx is found then the NFD peer simply rejects (or ignores) that tx permanently (and does not consider the bet wagers moved to winners/losers). Forgers who notice an invalid feed tx (that another forger lied) can correct it and possibly cancel the feed returning all the bets or even claim the other forgers TX fees. Cheating doesn't pay.
Cancel means pop the block -> fork. If you start creating transcactions which cancels old transactions, you can not trust any feed transaction, because there could be always a transaction in the future, which canels the current status. An attacker would only need a very small amount of NFD to attack NFD and always cancel every feed transaction.
So feeds move slowly 120 blocks behind and are eventually correct by forgers. Moving slowly is not a problem because the common case is that feeds do not need to be updated often (1 time per day).
Lastly feed validation has a maximum age (data sources don't last forever). After 60000 blocks feed outcomes become permanent and are no longer validated. In other words if a peer is re-downloading the NFD block chain very old feed tx's (60000 blocks behind) are not validated (the feed source may have died by then). It could make sense to lock feed tx's in (trust they have been validated already by the network) sooner, like after 480 blocks instead of 60000.
Let N be 240, 480 or 60000. The summary is that after N blocks any given feed tx is considered permanently validated and from then on is either used or ignored. The feed tx has had N blocks in which to be validated by the entire NFD network before it was "written in stone". This system is trustless because any attempt to cheat would be quickly thwarted. To cheat successfully the vast majority of forgers would need to become evil and collude, which would be against their best interests.
OK - let's simply it totally.
Another idea solving data source DDOS issue. "Confirmation by proxy." Forgers look back K blocks and re-validate/confirm previous feed tx's by adding special feed-re-confirm transactions. NFD peers validating blocks do not validate feed tx's at all, but look for feed-re-confirm tx's submitted by the forgers. The number of confirmations of a feed tx is NOT its depth in the block chain, but the number of miners who re-confirm the feed tx. If a feed gets 51/100 confirmations, then it would be considered valid by NFD peers and betting decisions made. Otherwise the bets could be canceled and money returned. This seems a lot simpler.
I see two other problems. An attacker could issue a feed with a malicus link to a new java exploit and kill the network.
Every forging node have to make requests to an external web site. Users who wants to stay anonym could have a problem with that.
