Message: 1 Date: Wed, 27 Jun 2001 19:03:21 +0200 From: Christoph Rabel To: mojonation-users@lists.sourceforge.net Subject: Re: [Mojonation-users] republishing and ID's Reply-To: mojonation-users@lists.sourceforge.net Andrew Loewenstern wrote: > This means that if anything changes: a file name, the "M" or the "N" of > the information dispersal algorithm, the way the file is cut into pieces > before applying the IDA and splitting each piece into blocks, etc... > then you will get a different Mojo-ID when publishing. Wouldnt it be better to remove the filename from the algorithm? One possible way would be to add it as a last step to the generated ID (encoded or not). Or reserve in the first or last block some space for the filename. So only the first or last block will be different. I know there are lot files out there that have different names but are the same. > aren't getting the same Mojo-ID. Try using the same version of Mojo > Nation and you should get the same blocks. Hmm, Im not 100% sure which one it was :-( And I have deleted all old versions, I didnt keep them. Maybe its better to forget the old files and start anew! Oh and, know this is just a beta version, but maybe in future releases it migth be possible to choose the encoding? greets Summand --__--__-- Message: 2 From: "Mirco Romanato" To: Subject: Re: [Mojonation-users] How Much Disk Space? Date: Wed, 27 Jun 2001 19:20:14 +0200 Reply-To: mojonation-users@lists.sourceforge.net ----- Original Message ----- From: "Mojo Eddie" > First I'd like to introduce the concept of relative and absolute > blockspace density. Blockspace just means the entire set of all > possible blocks. A particular bitmask specifies a particular > blockspace that is a subset of the entire blockspace; the size of the > bitmask determines the size of its blockspace. > The absolute density of a blockspace is simply the number of blocks > that are stored somewhere in the Mojo Nation system within that > blockspace compared to the number of blocks that the blockspace could > contain. For example, the entire blockspace can contain 2^160 blocks. > If there were, say, roughly a million blocks stored in the Nation > (let's say 2^20 blocks), then the density would be 2^-140. If the > blockspace were completely filled, the density would be 2^0, or 1. This imply that roughly there are space for 64 x 10^51 bytes or 64 x 10^41 blockserver with 10GBs of blocks. So, I think for the next ten-twenty years we will not run off namespace for blocks (provided no one implement real MNT on very large scale before - ehm near planetar scale). Evil Genius were very generous in namespace when started design the system, and this is a very good thing. > If D is 25%, then Q is about 2.4 queries. If D is > 10%, then Q is about 6.5 queries. If D is 1%, then Q rises to about > 69 queries. > Clearly, the system as a whole will benefit if as many blockservers as > possible have as high a density as possible. If everyone's advertised > bitmask is too small (meaning that their advertised blockspace is too > large), then it will become increasingly difficult to find a server > that actually has the blocks you want. The number are intersting in demostrating the common utility of enlarge as possible the bitmask. > So How Much Disk Space? > All of the above only concludes that for a server with a given amount > of disk space, the server will set its bitmask so that it reaches a > magic density where it is returning enough hits on queries to remain > in business but still has a large enough blockspace that it can obtain > as many profitable blocks as possible. It doesn't actually conclude > how much disk space a server should be devoting to its blockstore. > The answer is that it depends on how much Mojo a blockserver makes in > the long run, as measured per byte of storage. Since servers will be > tracking the profitability of each block, they can determine the > average profitability per byte across their entire blockstore. It > then becomes a question of how much real cost an operator incurs per > byte (including both money and time, and applying discounts for > altruism), and how much they value Mojo relative to their real costs. > And we won't know the answer to that until Mojo stops being play money > issued without limit and becomes a scarce (that is to say limited) > commodity. The real problem, as I understand it, is bandwidth not storage space. The servers will be stopped from do better transaction when he it the limits of its bandwidth. So, when the limits are touched is time to enlarge the bitmask and republish the other blocks. This will increase the density of the blockstore, so more search will success. The republishing feature will increase, also, the density of other blockstores. I like think about a way to republish the blocks that is "auto-fueling", so when the server sell blocks out of its (primary) bitmask it spend the mojo earned to republish the blocks (picking a random block). The storerage space is a no-problem because just now we have plenty of space available and if (WHEN) more users will add themselves to the nation the storage will grow-up; also every year capacity of HDs increase roughly of 70-100%. So if now an user volunteer 100 MB for the blockserver (but I think the average is more high - I bet near 650 MB), next year he will volunteer 200 MB (or if I win my bet, a GB). "Reality is that which, when you stop believing in it, doesn't go away." -- Philip K. Dick nameless.one@bigfoot.com Mirco Romanato Venezia - Italy --__--__-- Message: 3 To: mojonation-users@lists.sourceforge.net Subject: Re: [Mojonation-users] How Much Disk Space? Date: Wed, 27 Jun 2001 11:00:59 -0700 From: William Rucklidge Reply-To: mojonation-users@lists.sourceforge.net > If the blockspace were completely filled, the density would be 2^0, or 1. However, long before the blockspace completely fills up, there will be problems due to block collisions (two distinct blocks that have the same SHA-1 hash). If the hashes are distributed randomly, then once the number of blocks approaches the square root of the size of the blockspace, the probability of collisions approaches one. This is the "birthday paradox". 2^80 blocks is still a lot - that's 2^96 bytes, or about 10^19 gigabytes, so I'm not worried. -wjr --__--__-- Message: 4 From: "Mirco Romanato" To: Subject: Re: [Mojonation-users] Economics of Disk Space and Bandwidth Date: Wed, 27 Jun 2001 20:07:28 +0200 Reply-To: mojonation-users@lists.sourceforge.net ----- Original Message ----- From: "Mojo Eddie" > Note that while the blockservers currently perform wholesaling, they > pick blocks to wholesale based on popularity. They don't try to > determine what the current supply is, nor do they drop blocks by > preferring the most profitable ones, although there are notes in the > source code that say the Evil Geniuses are considering this. I think that is preferible, for the initial time, that the broker republish a block it would drop and enlarge the bitmask(s) so it could retain the more profitable blocks and contents will be no lost early and easily. Also, storage space is plenty. Maybe when republish a block the broker could pass to the blockserver the statistics about the popolarity of block, so in case a block is never asked for one year o more it will be dropped. "Reality is that which, when you stop believing in it, doesn't go away." -- Philip K. Dick nameless.one@bigfoot.com Mirco Romanato Venezia - Italy --__--__-- Message: 5 From: "Mirco Romanato" To: Subject: Re: [Mojonation-users] The Quest for Infinite Scalability Date: Wed, 27 Jun 2001 20:24:59 +0200 Reply-To: mojonation-users@lists.sourceforge.net ----- Original Message ----- From: "Mojo Eddie" > But to be scalable, > we need something else; the bitmasks need to be dynamically and > automatically adjustable, so that as more blocks are added to a server > with a given bitmask, it lengthens its bitmask as it starts running > out of space in its blockstore. The dinamicaaly and automatically adjustable bitmask must not be one but two. One first bitmask (the one that pubblicize the blocks the blockstore will accept to store from publishers) and a dinamiccaly varialble bitmask create to fit to the blocks that not fit in the first. This will be useful when resizing the first bitmask and we will not that all the blocks that don't fit the new (first) bitmask are dropped. When blockstore and bandwidth will run off, the mask will be resized and exceeding blocks will be republished --__--__-- _______________________________________________ Mojonation-users mailing list Mojonation-users@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/mojonation-users End of Mojonation-users Digest