That means a lot to me, particularly coming from someone like yourself!


I was extremely skeptical as well, at first, particularly considering the early design iterations were so rough around the edges.

However, having now spent many cumulative hours discussing (both zennet and a few other subjects) with Ohad both here and on IRC, pointing him toward materials on both the failed historical projects along these lines ("don't become another CPUShare" has become something of a mantra) as well as more contemporary research on how to overcome the problems they faced, reviewing videos and the slide decks from his various presentations on the project, and personally "half redesigning" his model myself along the way, I currently have very little skepticism left.

As his implementation work solidifies, my few remaining reservations should inevitably be addressed in due time, as well.

I pointed out earlier that even if he just runs off with initial investments we know well who and where he is.  People could just track him down and bring charges or beat him up or something.  So, if that is his intent, he has already made his work of a potential absconding very difficult for himself! 


Yes, my last response was probably a little too vague.  The payment model is a somewhat unique combination of on and off chain transactions.  What I should have said, to avoid ambiguity, is that there is no "off-chain accounting" involved, no centralized database of transaction, and all of the micropayments eventually (and intermittently) will end up on-chain.  In order to keep this convenient, the chain needs to be designed with a few particular considerations in mind (relatively fast block times, some specialized transactions, etc) which might potentially end up being at odds with the normal goals of an alt. (Wide adoption as a general payment vehicle, etc.)  Maybe these concerns can all be handled in a way that doesn't interfere with general purpose use, but this is not an explicit goal and if the model ends up not being suitable for broader use we shouldn't consider that any sort of failure or deficit of the implementation.


There is not really any explicit reputation system, only an implicit disincentive to not maintaining a good reputation.  There is no recorded WoT or direct positive/negative feedback rating or anything of that sort.  The system only provides a means for something that you might call "proof of cheats" which can serve to devalue a particular identity.  Ohad has already described one part of this, providers can intermittently be given deterministic challenge work.  As providers have to attest (by signed communication channels) that their identity performed the service, simply disclosing a signing of such an invalid deterministic work session (wrong results or resource applications for the given problem) can prove to third parties that the provider has behaved maliciously by interfering with processes.

Secondarily, publishers will receive from providers something of a "signed and authenticated receipt" corresponding to each resource and correlated billing.  These receipts can trace each individual resource billing to the specific resource access "expected" in the work algorithms provided by the publisher.  If these receipts show unreasonable charges from a provider, that do not follow the constraints of the work, the particular work unit and receipt can be disclosed together which can similarly prove to third parties that the provider has behaved maliciously by attempting unreasonable billing that cannot be justified by the work published.  I'd probably say that the planning of the mechanisms for these authenticated receipts has been my primary contribution to the design, so far.  These mechanisms, themselves, are all prior art published by others, I just pointed Ohad toward approximately the right combination of technologies to make it happen.  (I originally called for the processes themselves to be authenticated in such a way that the providers never even *could* perform incorrect billing at all.  We decided that the overhead involved in doing so would be far too prohibitive so the design that is going to be employed is something of a compromise albeit a very good one.)

Similarly if a publisher succeeds to avoid payment on a service agreement this becomes visible as a traditional double spend.

(There might be cases where both events occur, too!  A provider might cheat and get flagged, and a publisher might divert their payment in response, and the provider might announce this act as a non-payment. In fact, this might even be the common scenario of disputes.  It would be up to the third party to decide how to interpret this.  Likely they would look at additional context to "pick a side" or if there is no such additional context they would simply proceed with both parties considered to be suspect until some more context is formed around one or both identities.)

Although it took quite awhile for me to see it, this sort of implicit reputation model actually seems to mirror "real world" service billing transactions much more closely than any explicit reputation metric ever could.

My concerns there are much less to do with the reputation model itself (which seems to be minimalist but sufficient, which I consider to be a great thing though some might consider to be a weakness) and more to do with the initial identity generation process.  If identity generation cost is too low then there is little disincentive to just "cheating anyway" despite knowing full well that your identity will get burned.  If identity generation cost is too high it impacts usability and adoption rate.