LF: Fully Decentralized Fully Replicated Key/Value Store

But he should be working on getting it into people's hands, instead of creating new tech.

Seeing this leads me to believe that zerotier wants to do this whole global network thing. This is not what I want from zt.

This probably came from questions like "how can we trust you as a network controller". And the answer is to create some tech. But in that case, why not simply offer an AMI on aws for a controller?

All assumptions of course. Upon further checking:

From https://news.ycombinator.com/item?id=20329060 and https://www.zerotier.com/lf-announcement/ :

> We are going to use it to fully decentralize ZeroTier and for some specific enterprise customer projects, but others can use it for other stuff.

> Our interest in decentralizing the roots wasn’t just philosophical. Over the years we had numerous requests by policy-bound or very (justifiably) paranoid customers to run their own infrastructure that could be logically separated from ours as much as possible

I dunno. I'll have to see what it turns into. But it surely explains the silence and lack of updates on zt/zt-one

> adamierymenko 478 commits 403,913 ++ 148,611 --

Impressive productivity.. Worried about the Sybil attack. The documentation uses the "foolproof" wording, but the overlay might not be attack-resilient and creating a million fake identities would be sufficient to dominate the system. Even a loose connection to the main DAG might be sufficient to hurt LF.

> Oracle nodes document low reputation records in commentary records. When a node sees a commentary record it extracts this information and caches it internally in an indexed table.

That could be an attack vector. Broadcasting negative information can often be exploited in my experience. Slandering attack with a 100 Mbps VPS might cripple the network. Could this be altered into positive re-enforcement loop?

> Casual users can choose to trust nodes that are generally trusted.

How will central server "lf.zerotier.com" handle copyright claims by Hollywood (people will try to upload also large files)? (disclaimer, creator of Tribler, we're designing systems like this within our university lab for 14 years and 8 months)

Depends on what hardware the attacker has available. A GPU offers at least an order of magnitude increase in efficiency over a CPU, while FPGAs and ASICs offer further orders of magnitude increases. The particular PoW used here (birthday collision) aims to be memory hard but falls to a sublinear memory-time tradeoff.

That's assuming you need a reorg to adjust values. The original purpose of hashcash was anti-spam. That lends itself to allowing variable work factors and having the recipient's classifier regard higher work factors as a stronger not-spam signal, with the baseline set by the recipient administrator, or the mail daemon packager setting defaults for this year's distribution, as a trade off between false positives and false negatives.

Meanwhile a sender default of e.g. calculating hashes for ten seconds per message would cause the amount of calculation done to automatically rise over time as people buy faster hardware, but someone with slower hardware can reduce the false positive rate for their messages by increasing the time spent per message. Or someone with a high message volume but widely known and sterling sender reputation could reduce computation per message and rely on their good reputation instead, while less well known senders avoid spam classifications by doing more computation.

It works because it's all probabilistic anyway and having non-zero false positives or false negatives was already the status quo, so something that gets you closer to true is valuable even if it only solves 99% of the problem and not 100%.

Think of it (as the readme says) as consul for decentralized open systems.

There aren't any externally packaged drivers with a different licence, and you can't include their native code in your commercial projects without having to share the code due to the inclusion of the GPL3 licenced code.

    # openssl speed ecdsa
    Doing 256 bits sign ecdsa's for 10s: 494208 256 bits ECDSA signs in 10.00s 
    Doing 256 bits verify ecdsa's for 10s: 161277 256 bits ECDSA verify in 10.00s