Exciting project but it seems to have some external challenges for success

[BrandtH22]

I think the biggest challenges will be:

• ensuring that malicious actors cannot spoof space (essentially the multi-ip attack I mentioned and the peer data attack that dns mentioned)

• remaining profitable while also affordable (you mention it is 3 million times more profitable than farming and readily admitted that in a mature market that evens out but the other side of that is chia farming profitability could theoretically rise to a point where it is either not affordable to run a dig node or it is too costly to be a node sponsor)

• validating uptime and low latency (all of the Proof of Capacity coins rely on not just registering similar to the staking with dig but they also actively monitor each nodes specs and issue penalties for downtime and high latency. Without some controls in these regards the node sponsors will have highly differing results and potential poor experiences from nodes going offline or having high latency)

• preventing data injection (I assume the merkle tree hashes do this but wanted to make sure this is validated that node operators would not be able to inject data of any kind when serving the content from the data store)

• lastly the good ol regulations, with the SEC recently claiming that it does not matter if the software is decentralized there might be additional legalities to contend

[MichaelTaylor3D]

preventing data injection (I assume the merkle tree hashes do this but wanted to make sure this is validated that node operators would not be able to inject data of any kind when serving the content from the data store)

It should be very difficult to inject data that is not part of the merkle tree, the process is as follows

1. To start an upload session to a DIG Node, you have to present a serialized tree.
   • The name of the tree must match the root
   • The root must be on the blockchain
   • The root is recalculated from the serialized tree to make sure it matches
2. when uploading the files, you must have an active upload session still active which is bound to the merkle root.
   • Every file upload checks sha256 of the file and performs a merkle proof against the root. The file is only accepted if the proof is valid
   • If any files fail to validate their proof, then entire upload session is void and everything is rejected

When fetching the files from another DIG Node, a similar process is followed.

ensuring that malicious actors cannot spoof space (essentially the multi-ip attack I mentioned and the peer data attack that dns mentioned)

The DIG Network cares that content is available from a DIG Node, While it preferable that you have the data yourself, its not the primary objective. In the beginning it may be possible to "Make content available but not host it yourself" and technically thats allowed by the protocol. However, as the protocal becomes more mature, further development will want to make it as difficult as possible, To rephrase, this isnt as important in the short term as it is in the long term.

validating uptime and low latency (all of the Proof of Capacity coins rely on not just registering similar to the staking with dig but they also actively monitor each nodes specs and issue penalties for downtime and high latency. Without some controls in these regards the node sponsors will have highly differing results and potential poor experiences from nodes going offline or having high latency)

When validating content, the store sponsor can make short timeouts that require the dig peer to respond to the challenges quickly and ignore peers that respond past a threshold. This would make slow peers invisible to content delivery, although they could still contribute to file propagation.

When routing user requests to load content from various peers in the network, typically several peers might be requested at once and the first once to respond wins the race. Also for routing, currently we are just selecting random peers to load from, but later we can add more robust peer selection algrotims, for example only load from peers in similar geographic area.