Primes don't change as fashions do though. SHA1 is kind of arbitrary, kind of old, and the closer our SHA1-reversal rainbow-table gets to complete the less fashionable SHA1 will likely become.

So no, nice try but a bit of a fail there. Primes are ridiculously fundamental, though a way to construct them instead of having to go searching for them would be real nice.

-MarkM-

The signed transaction probably should be transfered in siged messages, signed by various personal or corporate identity and/or web of trust signatures, so there is not only a signature showing what bitcioin addresses committed to pay the amount but also which entity certified that they themselves issued that "signed bitcoin-transaction".

Maybe including pubkeys of actual entities the receiving addresses were believed to belong to, with signature from them certifying those receiving addresses are indeed theirs.

Then receiver of the junk "cheque" has legs to stand on come collection time or saleback-of-rep time.

-MarkM-

Thanks, I think we are getting somewhere.

However I am still tempted to try for competition and redundancy.

Assuming the market/escrow has the funds secured then how about not committing at the start of the month as to which storage provider to download the data back from during or at the end of the month? Instead, solicit from storage providers up to date indexes of which data blocks they do claim to have stored a copy of, while providing to them up to date counts of how many of their competitors claim to already have copied that block.

The storage providers would thus not be competing on price but on which blocks to store. They should prefer blocks none of their competitors have copies of yet. The more of their competitors who claim to have already stashed a copy of that block, the less desirable choosing that block as the next one to save a copy of ought to be.

The storage providers thus would be trying to get the newest blocks copied to their storage first instead of grabbing a copy of some older block, but also to grab a copy of any blocks that lost a lot of copies due to a lot of storage providers fading into the night.

The testing of whether they really have a block could be ongoing; each time one wants to host a block, they get it from one that has claimed to be storing a copy of that block. If we incite churn somehow, between them they will be in effect constantly checking each other's claims as to having a certain block stored. So lets list for each block not only how many claim to have a copy stored but also exactly when they made that claim or exactly when they made (according to their claim) that copy, and have some accounting mechanism along the lines of any copy that hasn't been copied by another provider in X amount of time is stale. It needs to be checked.

Since barring some clever proofs system the most complete check would be to download the entire block from them, maybe when it is stale it should also expire completely as soon as it has been verified, due to the verifying being simply to take possession of it. That is, maybe we should have the one that "verifies" it become a new holder of it on the list of who has a copy and since when and let the previous holder of it relinquish their claim so on the list it still shows the same number of claims-of-having-it even though someone else just checked one of the earlier claims in the process of grabbing a copy themselves to get themselves on the list of that block's current holders.

There is probably still room for gaming in this, as someone could set up large numbers of virtual machines that would grab blocks and claim not to have received a valid copy of the block, in order to attack a competitor's reputation. Maybe such a claim should therefore be a black mark against both parties: one seems possibly unable to copy a block correctly, the other seems possibly unable to provide a block correctly.

Hmm...

Also, why pay developers in devcoins? Well, devcoins are a side-effect of mining bitcoins. Admittedly namecoins and several other types of coin also are similar side-effects but the point is it costs no bitcoins to create them but they are sellable for bitcoins and fiat on markets so since no one seems to want to pay developers in bitcoins maybe these various side effect coins that happen while you mine bitcoins could be put to use in paying developers. People might feel more open-handed with things they get free as side-effects than with the main ore they are mainly mining for.

Also, the devcoins go out automatically. There is no need for a majority of devcoins minted to go to miners since miners already got paid for their work in bitcoins and in namecoins and maybe also in ixcoins and i0coins and coiledcoins, heck some might also have been paid in rucoins and/or geistgeld too, I certainly was for a while.

Why sell, or even pay people with, any ore you happen upon along side your gold in your goldmine, or alongside your platinum in your platinum mine, etc?

-MarkM-

For sure the storage providers should not to be able to read the files without the permission of the owners of the files.

There is plenty of free open source code that does that, in fact I have had the impression that part of what drove open source developers was often precisely the tendency of commercial service providers to set services up in such a way as to allow the providers access to as much of the customers' data as possible.

Just recently I was told that one share of devcoin generation is worth about 15 bitcoins. To me fifteen bitcoins is a nice amount to have flowing in regularly just as a side of effect of the fact I develop free open source stuff, and even a majority of the bitcoins I have made directly as bitcoins I received as bounty for working on devcoin and devcoin-related stuff.

It is true that each individual devcoin is worth far less than each bitcoin, but that was a deliberate design decision; bitcoins were skyrocketing back then, there was talk of having to move the decimal-point because users would find numbers with too many decimals awkward, so devcoin deliberately set out to be worth a thousandth or less of a bitcoin. 50,000 are minted per block accordingly.

The people who want to make coin by renting out space might be potential customers for the developers, but they are not potential customers for the users who supply the coins in the normal mainstream manner of thinking. Yes, bitcoin owners sometimes want to sell bitcoins, so any merchant willing to accept bitcoins is a customer of the person who sells them bitcoins in return for other goods or services, but if we take your view of wanting this project to be a consumer of bitcoins rather than a producer of bitcoins we want to be buying bitcoins not buying storage, right?

The people who have bitcoins do sometimes look for customers to sell them to, so maybe this is about how many of their offered bitcoins we can afford to buy given the amount of development ability and storage we can offer in return for their bitcoins.

Maybe we have to look at this in two layers: one, the person who actually wants storage. Two, the person who wants to sell them some. Three, the facilitator(s), which presumably amount to being markets, offering to bring buyers and sellers together.

To operate such a market, maybe a whole new asset-type, OSA (Online Storage Asset) would be useful. Persons wanting to sell storage could look at a prospective customer's OSA balance to decide whether that customer even has enough OSA to buy the storage the storage-vendor wants to sell, and the people wanting to buy storage could look at vendors BTC (BiTCoin) balance to see if the vendor has enough BTC balance to recompense any loss of data purportedly being stored. The market could act as escrow both for both the data stored and the coins paid. And yes I am thinking I mean here escrow of the actual data, not the abstract OSA asset. If the storage provider fails to provide the storage, the data stored on it can be recovered from the escrow aka the operator of the market? Hmm. Shoot that down for me, I am surely not seeing the problems with it clearly.

EDIT: I see one problem already: I seem to have shifted somewhere in that paragraph from OSA as a thing one buys storage with from storage vendors to OSA as actually stored data. I think that the confusion is that the OSA would amount to being coin/value that is commited to buying storage. Looking at someone's OSA balance is different from looking at their bitcoin balance because with bitcoins they might buy anything, so could spend it on something else. Their OSA balance though is purpose-specific. They already spent bitcoins or dollars or icecreamcones or sticks of gum or whatever to buy OSA units, now they are looking at vendors to decide which vendors to give them to. Something like that. I am getting confused.

...Maybe because of the layers. Coin vendors gave coins to the market/escrow, then the market/escrow is looking at storage vendors to choose which ones to obtain storage from...

-MarkM-

There is already at least one commercial pass-through app, or something very similar to it:

http://smestorage.com/?p=static&page=about#about-clouds

Google Drive does not mention mounting it as a drive in unix/linux using webdav protocol, but the chap who gave me the above link seemed to be saying that using that service he could use webdav to mount his google drive space.

Unthinkingbit too is concerned that developers of free open source stuff often are not paid well; that is why DeVCoins exist. Maybe DeVCoins would be more suitable than BiTCoins for developing this concept since implicit in DeVCoins is developers get coins. So far in your concept this is the first I have heard of any hint of a whisper of a suggestion that developers should get paid, it was all about users (of the software and the network of users it marshals) getting paid.

I wonder whether we even need random home-users though, maybe we should be looking at operators of virtual machines as our target nodes for acting as host nodes. Home users can be target consumers of storage, no need to use any of their own on site storage at all, what we would want them to contribute is coinage, not storage. Even if they do have lots of storage available, so what, that just means they are not likely to be a paying customer. No need to concern ourselves with them until they do not have enough storage and thus go shopping around for more.

In fact if we could estimate very firmly how many terrabytes of storage a large ISP's home-users would offer to sell and how much bandwidth that would cost the ISP maybe we could even go directly to the ISPs suggesting they sell us the storage cheaper than their users could due to not having the bandwidth cost of sending our data all the way to their users and back...

-MarkM-

I forgot to take into account the fact that of Nimbus.io's ten storage nodes per cluster only any two of the ten can vanish without losing data.

So each such cluster only really amounts to three copies of your data in a way since if three nodes go down ouch, pow, data loss.

They may well customarily keep people's data on more than one cluster at a time though.

I prefer watching the RetroShare folk looking out for potentially reliable ones to advertising a bribe because the bribe might bring all the bottom-feeders swarming in, all desperately trying to find a way to game the system. If I actually planned to attract those people I would try to design a system that would get as much use out of them as it can during the time they spend trying to game the system and failing, basically in effect planning to game those that try to game the system.

Part of why I was attracted to the RetroShare thread was they were not ostensibly just in it for money; it is even possible that what failed really was the backup bitcoin-forum the thread initially proposed. Actually it might not even be a failure, since maybe if bitcointalk forum does go down some day, all those RetroShare people will all fire back up their RetroShare, reconnect, and start actually using the bitcoin forums they created there. So maybe the real test of their reliability would be to turn off bitcointalk and see how many of the people hosting the backup forum on RetroShare actually do bring RetroShare back up.

Amazon's spot instances do use an auction where you only pay the minimum price needed to buy as much as people want-at-that-price. Everyone who gets an instance-hour in a given hour pays the same price per hour.

The why not dump all your users if someone else offers more could maybe be something insurance companies could cover? Post a bond with an insurance company, it then insures your users against you losing the users' data.

However I think maybe we are basically starting to glimpse *why* online storage *is* so darn expensive.

Maybe some pass-through apps would be useful, that let people go get their free five gigs of dropbox, google, etc, etc, all kinds of free for life storage, then do passthrough to others...

-MarkM-

There seemed no point in even considering offering any deals/offers/incentives to the RetroShare people, since long before enough time had gone by for me to start thinking "hey, some of these people seem to have been online 24/7 for a month or more maybe that could be useful" all but one of them had already demonstrated total lack of reliability. Heck it was days I think, though my sense of time is poor so maybe over a week, I suppose it may even have hit two weeks.

You make a good point though, good enough maybe to motivate me to turn on RetroShare every week-or-few and make deliberate note, maybe even written not merely a mental note, if I do happen to see a neighbor, of which one it is; so as to notice over time whether in fact it is the same one every time. If so that one might be worth thinking of for a scheme like this.

Basically the evidence was so overwhelming that the people were not reliable that the idea of offering to buy reliable service from them never even came up.

However I recently read somewhere that the length of time a host has reliably been online isn't actually much use in predicting whether they will stay online. Maybe some insight into whether they are actually making enough to cover expenses could help make such predictions though.

It seems a little like Amazon spot instances though in a way; any time the current bids outbid you, you lose your instances. Maybe the moment someone outbids you for storage, poof as much of your data as a financial-attack attacker chooses to displace with their own could be gone.

So maybe another metric to track would be what happens when you are outbid? Which hosts retain your data for how long in spite of higher bids being made bidding for the space they are providing to you?

Maybe we need time-scaled markets, covering for how long they will retain your data to give you a chance to move it or to increase your bid in the event you are outbid by how much? (If they are offered double the price you offer, how long grace time do you get? What if someone offers 10 times as much? 100 times as much? The ethical/moral equivalent of pool-hoppers will presumably be out there...)

-MarkM-

That worked. But now today my internet connection has been flaky and I0coin daemon has died twice saying

EXCEPTION: N5boost16exception_detail10clone_implINS0_19error_info_injectorINS_6system12sys tem_errorEEEEE
resolve: Host not found (authoritative)
i0coin in AppInit()

terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::system::system_error> >'
  what():  resolve: Host not found (authoritative)

Why the heck is it using DNS at all? None of the other (many) coin types are having this problem.

-MarkM-

Google Drive actually beats your example quoted price, something like $4.95 or $4.99 per month for 100 gigs of storage, no mention of any upload/download fees on top of that, at least not that I noticed. Like dropbox I guess they are going for simple instead of frightening the common people off with nickel and dime stuff that could add up to some unknown in advance total. If you want larger quotas, prices per terrabyte keep going down in more steps as you upgrade to larger quotas.

Nimbus.io offers $6 for 100 gigs, with also $6 per 100 gigs of transfer. ($0.06 per gig for each), and they are free open source software so that anyone who wants to set up storage servers in clusters of ten for parity-striping of data onto ten servers at a time can do so. (So we know they are based on ten hosts at a time, so lets figure we'd have to charge no more than a tenth what they do if we want to offer one host at a time prices.) Their software obviously is set up to do just the kind of pricing in your example quote so maybe if you set up ten virtual machines on your machine you could use it even for just one machine. It has the website, customer info handling and everything by the look of it.

I have found out more about GNUnet. It actually does not "publish" files out onto the grid at all, replication is only an efficiency thing, in that if anyone actually does ever ask for a copy of your file, then it will tend to persist some time at the mode that requested it and possibly even at places along the way to the requesting node. So you don't "push" your files out, instead someone out there has to request from you. Still, given a way of telling a particular node a file to request from you, it could be useful.

Unfortunately though I think most fly by night random hosts that fire up some software to see if it will earn some pennies are not going to be useful for storage. They could provide nice random topology for complicated routing of transfers for anonymity purposes but there is so much chance of the user turning off the machine when they go to bed, or killing the app after half an hour to a few hours when they get bored of playing with it and have not seen any pennies trickling in, that that there seems little point sending them any blocks to store except maybe a canary - a test block to ask for next week if they even manage to stay online a week, which they likely won't.

Did you see the Retroshare thread? I had 28 or more bitcointalk users as "friends" in that friend to friend network, and within a few days tended to have usually no connections, occassionally seeing one connection and maybe catching a glimpse of two for a moment. And this is bitcoiners, a population among whom many have machines that are running 24/7. Among "normal" people I wouldn't be surprised to see even worse results.

I would have needed every single one of those 28 people to have a copy of my data in order to have found one copy still reachable ofter a few days or maybe a week or two, the short time it took for the vast majority of them to fade into the night.

So your idea of lets buy three sites worth seems tragically low. Better buy 30, and still recognise that just gives you a chance one might survive to the end of the month maybe, if the people involved are as used, on average  to keeping their machines on 24/7 as bitcoiners (or bitcointalk members anyway) on average are.

-MarkM-

Hmm...  If we can actually know the relative resources of the participants then we could set the risk deposit in proportion, to try to make sure that, for example, if C has ten thousand times as much total resources as A, the risk deposit is ten thousand times as much as A stands to lose, so that for C to uses it vast resources to "bully" A by thinkign to iself "hey, A only has so much capital, if I keep making sock-puppets who suck A into traps where the sock-puppet and A both lose, I can eventually fritter away all of A's resources at a cost that is only a trivial fraction of my own resources. How much exactly would it be worth to me to cause A some losses?"

The problem is we would presumably have to assume any possible C we do not have total transarency into the total capital and political capital or alliances and so on of to be a sock-puppet of some guesstimated/imagined potential large spendthrif enemy that might be out there somewhere creating sockpuppets seeking to get that attack-vector C-position in transactions of this type?

-MarkM-

(...You didn't say how many separately-sited copies of your data dropbox's offer is/contains/represents...)

Okay, I have spent the night digging back into the details of various actually currently working software that I could run, but as you did not indicate what operating system you plan to use to provide the storage you are at least hypothetically offering I do not know if you could run them.

I am finding so far only two systems I actually have managed to get installed and working that seem like one or more of them of them might suffice for an offer such as is quoted above.

That is, putting aside all the theory and vapourware-wishlists and philosophy and looking at that specific offer as a potentially-tangible offer.

Those two systems are GNUnet, which currently requires a unix-type operating system to run, and Tahoe-LAFS, which is python and seems to think it is usable even on Windows.

Part of the differences between them is that GNUnet is not only about storage, so it has the "overhead" of trying to provide some anonymity. Requests sent out do not have to originate at the node your node receives them from, and nodes deliberately keep packets moving as background noise all the time so that timing attacks cannot notice aha look that node talked to that one, without having heard from another one recently, so I bet it originated that request itself.

So if you do not want anonymous routing going on,  Tahoe-LAFS seems cheaper in resources to use as provider, provided your customers don't want the kind of anonymity GNUnet adds into the service-offering.

However, Tahoe-LAFS is organised as "grids", each "grid" being basically the collection of nodes a particular "introducer node" is able to introduce clients to. So in order to offer a Tahoe-LAFS based service you'd either have to have a few machines, probably best not all being in one site; or a number of us would have to team up to make one or more "grids" we would between however many of us be able to populate with enough machines, at enough sites, to be able to present the services of our "grid" as a credible service-offering.

I suggest that if you wish to sell your $5/month offering we should maybe consider teaming up with a third person so we can have at least a three-sites grid running, and consider whether to each use the price shown in the quote, totalling $15/month for someone wanting all three of us to store that much data for them so they have three copies out on the grid; or consider charging slightly less per redundant copy located at separated locations.

Did you happen to notice how many separate sites how many copies of your data the $20/month commercial offer was offering?

Despite the "overhead" of the (possibly extraneous to many people) anonymity that GNUnet provides, I think we would be better advised to go with a GNUnet solution, partly because using Tahoe-LAFS we would be trying to compete very directly against commercial services.

I am thus thinking lets start small, using GNUnet, then as we get customers for that "value (of being anonymous) added" service, revisit the price per gigabyte per separately-sited copy we could offer and whether it would be worth our while at the rates trying to compete with the commercial services would force us to drop our prices to.

WIth GNUnet we not only get to have this "value adding" feature of the anonymity stuff, but also the "it runs itself" feature of quite possibly providing quite a lot of its participants enough offsite storage and anonymous packet routing just in node to node barter that we could all have a useful number of usefully stable offsite backups without having to sit down and figure out how much bitcoin to send each other at all. The system has the virtue that we can all have these things for ourselves by barter up to the point where someone wants to receive more service than they provide. Those people will become thereby the potential "customers" who might go shopping around among those of us who have stably, long term, reliably had service to spare that we can offer them.

Basically it should find out for us automatically who among us actually does have surplus available and who among us is suffering sufficient shortfall of provision to start thinking about spending some bitcoins having in a sense run out of actual service of their own to barter with.

With Tahoe-LAFS, not only are folks not anonymous but also we each have to jump through gosh knows what hoops to figure out how much of our resources which other person is consuming more of than we are consuming of their resources. The administrative overhead thus looks like it would be much higher  not onlly for those actually providing service but also for those wanting to leech or buy service (the potential "customers" among the participants).

-MarkM-

Lets translate that question a litttle to make it clearer what is being asked:

"How would tracking [quantity of product offered for sale] be any different from tracking [quantity of currency offered in return]? They're both just numbers..."

-MarkM-

Don't get confused by the variable-names or metric-labels:

"Pay bitcoins if you need [RESOURCE_OR_SERVICE], receive bitcoins if you rent it out."

If what you need is, purely and solely, storage space, have you compared the monthly cost per terrabyte of writeable DVDs plus the oneshot upfront cost of installing enough DVD drives to put that much DVD space online all at once at your own location?

If what you need is, purely and simply, offsiteness of space, have you compared the monthly cost per terrabyte of sneakernetting or snail;mailing the DVDs to an offsite location?

If what you need is purely and simply, transport from onsite to offsite, again compare DVD-by-sneakernet.

If what you need is, purely and simply transport from offsite to onsite, again have you compared price of DVD-media transport?

It continues to sound though as if you are actually trying to palm of or fob off some dynamic combination of probably at least three of these pure and simply commodities onto a one-dimensional metric (known as bitcoin) that already carries the burden of also having to be equal to dynamic quantities of an endless number of other pure and simple things and complicatedly dynamic things and indeed any thing or service whatsoever.

If you really want to take it down to how many bits you receive from offsite, how many bits you send offsite, how many copies of each bit reside on each reliability of peer storage reachable at each possible bits per second rate at what percentage chance on any given second, minute, hour, day, week month or year, that is vastly complicated set of markets, where you or your agent needs to determine how many bits per second seconds how many bitmonths of how likely to be accessible when you need it storage is equal in value to you to how much more or less of any of those factors. How much do you value the snappiness of response, as measured in number of bitmonths stored? Does it differ according to how many bitcoins the material requested has been stored? And on and on and on. Is two bytes of storage worth more or less to you than two bytes per timespan for two timespans of transport? Is outgoing transport worth more or less to you than incoming trasport? Etc etc endlessly.

Once all these factors as to your personal preferences as to when you want how many more bits per second rather than how many bitmonths of remote storage in use and so on and so on have been all reduced down to a single scalar numeric value, then how many satoshis or bitcoins are  you willing to pay per how large a value of that scalar metric can be tested by offering you such a scalar on a market.

If however you insist that the scalar itself be labelled bitcoins, then it is reduced to a market in which the commodity being auctioned off is known as bitcoins due to your insistence that the scalar result of the reduction of the commodity to a single scalar must be bitcoins rather than being number of bits of data you have on offsite DVDs available by sneakernet using couriers, or speed of vehicle said couriers will use up to and including putting the DVD into a transporter so it materialises on your desk or directly changes the magenetism of your hard-drive.

It is too vast a field of not-the-same-thing that you are trying to boil down into one thing. Having boiled it down to one thing, whatever one thing you boil it down to so as to have a BTC<->ThatThing market, if you insist that thing ITSELF must ITSELF be known as bitcoins rather than being known as "general scalar metric of offsite-storage-network resource consumption quota" you will just end up with a totally confusing market, a "BTC meaning the digital currency"<->"Bitcoins meaning the metric of usage of network storage resources subsuming upload volume, download volume, storage volume and duration, bits per second sustained of download, bits per second burst of download, bits per second sustained of upload, bits per second burst of upload, and other ancillary factors".

It seems simpler and clearer to use some word other than "BTC" or "Bitcoin" or "Bitcoins" for that second metric, the commodity metric being offered for sale not AS bitcoins but IN RETURN FOR bitcoins.

In GNUnet, if I recall correctly, that commodity-provided-by-this-system metric is stored in a variable some coder or other happened to name "karma".

It is simply a human-and-compiler-readable label meaning "that scalar value which serves as the numeric metric of the commodity provided by this network/application".

Hindu or any other mysticism might only be some strange random reference that coder happened to find useful at coding time as a mnemnonic by which to refer to that variable/metric.

So for your purposes maybe it would suffice to use a preprocessor macro to change the name of that variable to QUANTITY_OF_SERVICE_DESIRED_BY_USER so that you will be able, upon reading the code, to make the mental leap to the aha moment that, in such a network, THAT is the variable you would be best served by spending your bitcoins to buy an increase in numeric value of the bits that variable refers to as interpreted as representing a number.

Or, you could chose to change its name to AMOUNT_OF_STORAGE_DESIRED everywhere instead, while people also interested in how much speed it amounts to rather than how many years bits offsite will survive if they don't request them for years could use some other label for it.

It is a complicated service involving redundancy and latency and bandwidth and on and on and on. Marketers would love to game you by offering a different product, different in any of the details that go into the whole generic concept of getting your bits offsite and being able to get them back onsite, whether by dialup or sneakernet or wireless or TCP or UDP or whatever, so they can claim to be a different product entirely, maybe not even a commodity (generic) product even maybe but rather a prestige boutique product incomparable to commodity offerings so they belong on a different market entirely and should not be compared to commodity offerings, especially not on price, since afterall their vast marketing budgets and ridiculously ignorant user-bases' need for hand-holding's accomodation by vast helpdesk centres precludes any comparison to any raw commodity.

To be a commodity that can be assigned a scalar value in bitcoins,  a thing has to be gotten down as close to a scalar value as possible first in order to have a single value, usually labelled quantity (as in X number of porkbellies, X number of grams of gold, X number of remote storage bitspeedmonthdirections or whatever), so that a market can be a "quantity of money" <-> "quantity of that very very specific commodity" market.

Notice even the grams of gold might be this that or the other fine-ness of gold, so even there there are more variables that in casual chat one takes for granted but that in fact a .999-fine grams of gold market is distinct from a .333-fine grams of gold market and so on.

To commoditise a thing you need to get it condensed down to the point where a market offering a scalar value of it per scalar value of a currency makes sense to the participants.

Already in Open Transactions we are seeing how fragmentation of markets scares off potential customers, with some potential customers thinking that having separate markets for ones of bitcoins, tens of bitcoins, hundreds of bitcoins (or s/bitcoins/porkbellies/ or s/bitcoins/shiploads of porkbellies/ or s/bitcoins/grams of porkfat/ or whatever, an assset is an asset is an asset, all are tradeable each against each) is in some way bad or awkward or "too complicated" or something even though in business it is actually very often the case that the price of grams of something, per gram, differs from the price of tons of that same thing, per gram.

So dont keep getting hung up on the name of the variable that serves in the code as the measure / metric of what it is that is being provided, instead consider whether that which is provided suits your needs and whether you wish to be provided with more of it or less of it than you are currently being provided. If you want more of "the service", get that number increased, whether by paying bitcoins to have it increased or by whatever other means. It is the measure aka metric of the service provided by that software.

-MarkM-

If karma works right, which it is intended to and thus hopefully in some version of the software will do, and might in fact already do, then it should condense nicely all that complication down to a simple do I need more karma with more other nodes or am I satisfied with the level of performance my existing karma provides.

-MarkM-

Okay then great. The store blocks on speculation model might work at least for some data. For example if you don't mind the data being stored in legible form, in the sense that anyone who would like a copy is welcome to buy a copy and is not likely to have any trouble executing it or displaying it or playing it - in general, "using it" - then heck thousands of nodes might eagerly store it for you forever just on the strength of the income they hope to get by selling it on to others.

As we have seen from the difficulty of finding hash collisions though, if the data is encrypted the chances are very low that anyone other than you will ever be paying us for a copy of some random block of an encrypted file only you know the key for, so the future looks kind of dim unless we do have some reason to believe you either will buy it back or might very unlikely buy it back but will pay well for it if you ever do. We'd store your data on speculation, much as some three-letter agencies maybe try to store every phone conversation that ever passes over international lines or some other vast collection of possibly largely/mostly useless information.

But is it important for us to care whether or not that is how karma points actually work inside the code/network?

Can we mere humans not get along fine simply deciding whether or not to buy our node some more karma points instead of worrying about the nitty gritty details of how this version or the next updated version of the software actually does its wheeler-dealer dealing to come up with the karma balances it assigns to its neighbors?

Don't we really just want our backups when our local system crashes? Or want our photographs back that we moved offsite without even keeping a local copy of?

Certainly I want offsite backups, real ones in the sense that I actually can get a copy from offsite if my onsite data ever does get lost thus create a need for restoring from backups and my onsite backups also are lost. It would be nice if some shopping app could shop around and find the best price for sufficiently reliable storage but its not as mission-critical as actually having such backups in place.

Right now I could pay bitcoins for karma points on other people's GNUnet nodes if my own GNUnet node turns out to have insufficient karma to accomplish this critical mission.

It happens though that I have not yet experienced sufficient shortfall of such points to be aware yet of any current need to boost my karma by paying for karma points. Maybe other people have?

-MarkM-

Ok that is strange, I had the impression that since you cannot know until the the information is delivered back to you or some kind of N-knowledge proof (where N might even be zero even???) proves they do still have it when the time you paid for is up, and possibly even had it constantly between the start of the timespan and the end of the timespan, they they actually did store it.

Thus my impression had been that it is better to pay after the fact for performance than to believe bids up front.

Thus I thought an "I will pay X for block Y" much more robust.

I suppose maybe asking for estimates ahead of time for how much the network thinks it might cost to buy such a block some certain timeperiod after you submit it for consideration might help give you hints about how often to buy a copy for how much in order to ensure someone out there will be eager to sell it to you next time you ask for it, but really, if it turns out you can get it cheaper from numerous providers than the initial estimates you were given, why not go the cheaper route?

However, I guess you are more in the market for some vapourware-provided service than for something people can actually fire up an app to provide to you by the sound of it?

Is there any bounty offered for moving this vapourware onward toward people being able to actually store your, uh, how many bytes exactly for, uh, how long a timespan is it you want it stored for? Oh and how much are you offering for storing the data once the software to do this for you has been gotten up and running?

I am trying to move on to actually getting offsite backups up and running, having to wait for some vapourware first isn't very appealing. I'd prefer to get to a point where people can store data and can if they wish use bitcoins to encourage the robustness of the storage solution before waiting for some future development that might make doing that even easier than it already is using already working code.

-MarkM-

I have read a lot of such material on many distributed storage systems.

I guess if you are offering to buy a resource and can provide the software or provide a URL to download a free open source implementation of the software to provide you that resource, I'd consider installing it and selling you the resource maybe depending on how much of the resource you want to buy how regularly for how long.

These karma points are basically just another resource, they can be experienced as disk space and/or as bandwidth, a kind of spacetime resource maybe. If you don't want to buy that, point to code that explicates executably the precise resource it is you are looking to buy.

-MarkM-

What service?

DIstributed storage tends to be crypted blocks, so maybe you want to buy blocks? Specific blocks, offering more for hard to find blocks than for blocks you can get swiftly and easily from umpteen providers?

-MarkM-

EDIT: Example: you pay nodes to let you send them a block. They wonder whether the block will ever pay anything more than what you paid to have them let you connect to them and deliver it. Some day you offer them bitcoins for a copy of it. You pay well, and pay them to let you tell them the bits of another block you might or might not want to buy a copy of at some later date. Etc.

I suspect a karma<->BTC market might well work better. A human might not hover all day over their node day-trading karma, but might some friday night upon noticing their node didn't have enough karma to fetch them the data they asked for on monday decide to give it some bitcoins so it can buy some karma to see if that can manage to get the data before the weekend is over...

Okay so lets rename karma as bitcoins. Or as satoshis or as millibitcoins or whatever.

Are you also proposing that the nodes mine bitcoins?

If not, how will any node ever actually convince its owner to provide it any bitcoins?

Are you planning to put some bitcoins in your node's wallet? If so, how many?

I figured, maybe wrongly, that most people who install the software to see if it can make them some pennies will most likely initially run it a while to see how many pennies it brings in before considering whether maybe their node simply isn't competetive enough to bring in any and from there whether they have any actual use for distributed storage themselves that might justify providing their node with some bitcoins instead of leaving it bring in bitcoins itself.

So maybe lets intially survey how many bitcoins are on offer, in order to consider whether to even bother firming up the details of the contemplated software so that folks can run it to harvest those offered coins...

...Or, we could use the already existing so called karma points for now, with an eye to figuring out whether in the end we will be calling them satoshis or bitcoins or millibitcoins or what.

Failing that, what exact services do you wish the markets to offer up for sale for bitcoins? Bits per second seconds of data-transfer maybe? Along with bits per second or day or hour or year or whatever of storage? Or, pay per block, you bid X satoshis for block ASghk235bbld6w566bnlwlsl66 and first node to deliver it gets paid? Or what?

-MarkM-

This is expected to be distributed, possibly somewhat in the spirit that bitcoin itself is, right?

We have seen with bitcoin that securing against attack tends to come down to how much it costs to defend it versus how much it costs to attack it, along with hopefully being able to make defending it seem more rewarding to potential attackers than attacking it so that some potentail attackers might decide the luls plus possibly even profit to be had by some ingenious attack are outweighed by the profits to be had by co-operating with the defenders.

So basically it seems to come down to how much is bid by defenders to have their data actually survive versus how much might an attacker pay to have someone's or everyone's or anyone's data not survive.

Is the ultimate purpose to run an experiment to see whether defenders choose to outbid attackers, or to create one or more markets where speculators and manipulators and brokers and shorters and so on can wheel-and-deal, or to get software working that can "equably" or some such term balance the resource contributions of nodes, onto which can then be added some means by which money  can be applied to influence which nodes that are not contributing are nonetheless provided use of resources?

I am proposing the latter: first make sure the thing actually works fine when nodes are not being paid money to service "nodes that normally would be allocated less resources than their owner desires due to providing less resources than they consume".

Basically the idea is we will not know which nodes have excess resources and which have shortfall of resources a-priori ahead of time.

For example even though a human owner of a node might imagine their node to have an excess of disk space could in practice find the space turns out to be offset by their node having a shortage of bandwidth, or of uptime, or of data integrity in terms of actually providing people with the data people thought it was storing for them at the time that they wish to access it, or whatever.

For example I think GNUnet uses "karma" as its internal currency-type-thing. Merely having a lot of disk space might or might not turn out to result in gaining more karma than you lose in the accounting of various other nodes depending on how karma is actually computed and what exactly actually happens in the way of blocks being stored, blocks being requested, the speed with which requested blocks are delivered compared to the speed from which they can be obtained from other nodes, basically whatever heuristics are in the code.

It might turn out that the way to make a trickle of pennies is not so much to have lots of disk space but, rather, to provide really low latency high bandwidth delivery of data stored on such disk space as you do have.

Once the heuristics the system uses internally to assign karma to other nodes work well, then maybe it would suffice to simply have a BTC<->karma exchange where people can buy karma points for their node on nodes of their choice using bitcoins.

But until karma points work well, maybe such a market wouldn't really be all that useful or great as markets for really great products likely do better than markets for products that don't actually work very well.

-MarkM-

EDIT:

Some distributed storage solutions drift the blocks toward the places that rquest them, so that for example if lots of people at a particular ISP ask for certain files and if the ISP itself was a node along the way for those people, more and more often more and more blocks of the popular-with-them files would tend to have migrated closer and closer to them.

Now imagine if speed were a factor, possibly in addition to how distance is in that solution. Having huge amounts of disk space might be almost worthless, since small-storage nodes with high speed might turn out to be the usual nodes most people get a copy of something from, with the huge disk drives having slow bandwidth becoming places only resorted to if it turns out each and every really fast node turns out to not have a copy of something the vast disk slow bandwidth node has. Thus the huge disks could idle unused for years before some partocular block of some particular ancient file no one has enquired about for years turns out ot be available from the huge slow node...