<div dir="ltr"><div>Thanks Dirk, I'll be sure to check all those out as well. Haven't yet heard of spinal codes.<br><br></div><div>Natanael, all of the mining is based on the amount of storage that you are contributing. If you are hosting 100 nodes each with 10GB, you will mine the same amount as if you had just one node with 1TB. The only way you could mine extra credits is if you could convince the system that you are hosting more storage than you are actually hosting.<br>
</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Dec 1, 2013 at 2:40 PM, <span dir="ltr"><<a href="mailto:jason.johnson@p7n.net" target="_blank">jason.johnson@p7n.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div link="blue" vlink="purple" lang="EN-US"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">What if you gave them the node to use. Like they had to register for a node. I started something like this but sort of stopped because I’m lazy. <u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""> <a href="mailto:tahoe-dev-bounces@tahoe-lafs.org" target="_blank">tahoe-dev-bounces@tahoe-lafs.org</a> [mailto:<a href="mailto:tahoe-dev-bounces@tahoe-lafs.org" target="_blank">tahoe-dev-bounces@tahoe-lafs.org</a>] <b>On Behalf Of </b>Natanael<br>
<b>Sent:</b> Sunday, December 1, 2013 1:37 PM<br><b>To:</b> David Vorick<br><b>Cc:</b> <a href="mailto:tahoe-dev@tahoe-lafs.org" target="_blank">tahoe-dev@tahoe-lafs.org</a><br><b>Subject:</b> Re: Fwd: Erasure Coding<u></u><u></u></span></p>
<div><div class="h5"><p class="MsoNormal"><u></u> <u></u></p><p>Can't you pretend to run more nodes than you actually are running in order to "mine" more credits? What could prevent that? <u></u><u></u></p><p>
- Sent from my phone<u></u><u></u></p><div><p class="MsoNormal">Den 1 dec 2013 17:25 skrev "David Vorick" <<a href="mailto:david.vorick@gmail.com" target="_blank">david.vorick@gmail.com</a>>:<u></u><u></u></p>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in"><div><p class="MsoNormal" style="margin-bottom:12.0pt"><u></u> <u></u></p><div><p class="MsoNormal" style="margin-bottom:12.0pt">
---------- Forwarded message ----------<br>From: <b>David Vorick</b> <<a href="mailto:david.vorick@gmail.com" target="_blank">david.vorick@gmail.com</a>><br>Date: Sun, Dec 1, 2013 at 11:25 AM<br>Subject: Re: Erasure Coding<br>
To: Alex Elsayed <<a href="mailto:eternaleye@gmail.com" target="_blank">eternaleye@gmail.com</a>><br><br><u></u><u></u></p><div><div><p class="MsoNormal" style="margin-bottom:12.0pt">Alex, thanks for those resources. I will check them out later this week.<u></u><u></u></p>
</div><div><p class="MsoNormal" style="margin-bottom:12.0pt">I'm trying to create something that will function as a market for cloud storage. People can rent out storage on the network for credit (a cryptocurrency - not bitcoin but something heavily inspired from bitcoin and the other altcoins) and then people who have credit (which can be obtained by trading over an exchange, or by renting to the network) can rent storage from the network.<u></u><u></u></p>
</div><div><p class="MsoNormal" style="margin-bottom:12.0pt">So the clusters will be spread out over large distances. With RAID5 and 5 disks, the network needs to communicate 4 bits to recover each lost bit. That's really expensive. The computational cost is not the concern, the bandwidth cost is the concern. (though there are computational limits as well)<u></u><u></u></p>
</div><div><p class="MsoNormal" style="margin-bottom:12.0pt">When you buy storage, all of the redundancy and erasure coding happens behind the scenes. So a network that needs 3x redundancy will be 3x as expensive to rent storage from. To be competitive, this number should be as low as possible. If we had Reed-Solomon and infinite bandwidth, I think we could safely get the redundancy below 1.2. But with all the other requirements, I'm not sure what a reasonable minimum is.<u></u><u></u></p>
</div><div><p class="MsoNormal">Since many people can be renting many different clusters, each machine on the network may (will) be participating in many clusters at once (probably in the hundreds to thousands). So the cost of handling a failure should be fairly cheap. I don't think this requirement is as extreme as it may sound, because if you are participating in 100 clusters each renting an average of 50gb of storage, your overall expenses should be similar to participating in a few clusters each renting an average of 1tb. The important part is that you can keep up with multiple simultaneous network failures, and that a single node is never a bottleneck in the repair process.<u></u><u></u></p>
</div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">We need 100s - 1000s of machines in a single cluster for multiple reasons. The first is that it makes the cluster roughly as stable as the network as a whole. If you have 100 machines randomly selected from the network, and on average 1% of the machines on the network fail per day, your cluster shouldn't stray too far from 1% failures per day. Even more so if you have 300 or 1000 machines. But another reason is that the network is used to mine currency based on how much storage you are contributing to the network. If there is some way you can trick the network into thinking you are storing data when you aren't (or you can somehow lie about the volume), then you've broken the network. Having many nodes in every cluster is one of the ways cheating is prevented. (there are a few others too, but off-topic).<u></u><u></u></p>
</div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal" style="margin-bottom:12.0pt">Cluster size should be dynamic (fountain codes?) to support a cluster that grows and shrinks in demand. Imagine if some of the files become public (for example, youtube starts hosting videos over this network). If one video goes viral, the bandwidth demands are going to spike and overwhelm the network. But if the network can automatically expand and shrink as demand changes, you may be able to solve the 'Reddit hug' problem.<u></u><u></u></p>
</div><div><p class="MsoNormal">And finally, machines that only need to be on some of the time gives the network a tolerance for things like power failures, without needing to immediately assume that the lost node is gone for good.<u></u><u></u></p>
</div><div><p class="MsoNormal"><u></u> <u></u></p></div></div></div><p class="MsoNormal"><u></u> <u></u></p></div><p class="MsoNormal" style="margin-bottom:12.0pt"><br>_______________________________________________<br>tahoe-dev mailing list<br>
<a href="mailto:tahoe-dev@tahoe-lafs.org" target="_blank">tahoe-dev@tahoe-lafs.org</a><br><a href="https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev" target="_blank">https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev</a><u></u><u></u></p>
</blockquote></div></div></div></div></div></blockquote></div><br></div>