5 ms·

>Proof of work is not foolproof, especially in LF where there is no intrinsic economic mechanism to incentivize the runaway growth of PoW "mining" investment. A

>Proof of work is not foolproof, especially in LF where there is no intrinsic economic mechanism to incentivize the runaway growth of PoW "mining" investment. As a result a well financed or determined attacker willing to throw a lot of compute power at the problem could overcome the PoW "weight" of the records beneath a target record in the LF DAG and replace it. This issue -- of creating equivalent proofs of work -- is what I was most interested to see if there was any novel art (which it appears there isn't). Bitcoin's difficulty adjustment is the only well-functioning algo that deals with the economic coordination issue around how to -- without any third party coordinator -- equate the value of a proof of work made by computer's of differing computational capacities (a phone, an ASIC). All PoW consumed by Bitcoin has marginally positive contribution to the system. Sacrificial PoW (as in LF, hashcash) only has value if reorgs happen. It also results in a system with tenuous game stability properties ("When will it be uneconomical for an attacker to reorged these records out of the DaG?" "Can't say, blocks' PoW requirement is arbitrary") vs bitcoin ("When will this 50 BTC txn be uneconomical for the most adversarial miner to reorg out?" "well there's about 14 BTC of block reward per block so about 4 blocks ~40-60 minutes"

synctext 7y ago
Fascinating project. It is the first time I've seen proof-of-work combined with DAG and real world engineering details such as PulseToken, oracle nodes, varient on S/KEY one-time password scheme, etc. > 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)
- hoseja 7y ago
  > MaxFileSize: This limits the maximum size of locally written files. Files larger than this can appear if someone else wrote them. The hard global maximum is 4mb. Note that large files can take a very long time to commit due to proof of work on public networks!
  - synctext 7y ago
    Makes sense. Is there a measure against spamming the network with 1 billion files of 1 Byte each? (besides PoW)
- api 7y ago
  The lf.zerotier.com node is just another node. It's just hard coded as a default so people can use the CLI right away. It has no special status and could be taken down with no effect on other nodes.
tromp 7y ago
> When will it be uneconomical for an attacker to reorged these records out of the DaG? 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.
zrm 7y ago
> Sacrificial PoW (as in LF, hashcash) only has value if reorgs happen. 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%.

synctext 7y ago

Fascinating project. It is the first time I've seen proof-of-work combined with DAG and real world engineering details such as PulseToken, oracle nodes, varient on S/KEY one-time password scheme, etc. > 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)

hoseja 7y ago
> MaxFileSize: This limits the maximum size of locally written files. Files larger than this can appear if someone else wrote them. The hard global maximum is 4mb. Note that large files can take a very long time to commit due to proof of work on public networks!
- synctext 7y ago
  Makes sense. Is there a measure against spamming the network with 1 billion files of 1 Byte each? (besides PoW)
api 7y ago
The lf.zerotier.com node is just another node. It's just hard coded as a default so people can use the CLI right away. It has no special status and could be taken down with no effect on other nodes.

tromp 7y ago

> When will it be uneconomical for an attacker to reorged these records out of the DaG? 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.

zrm 7y ago

> Sacrificial PoW (as in LF, hashcash) only has value if reorgs happen. 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%.