Topic: [ANN] Storj - Decentralized Storage - page 116. (Read 389670 times)

Node A seems a bit more my case because being a Time Warner Cable-ian, I have 16 Megabit down and 1 Megabit up. Storing things is no problem for me. Sending them back, maybe.

Our development process is very different from most. We want to provide working solutions one by one than promising you the moon, and taking 3 years to deliver. In our first development run, you can run web nodes that sell bandwidth. These nodes sell bandwidth, and shuttle files around the network.

Lets say:
Node A: Is a node with 56 KBit/s and 1 TB storage
Node B: 10 MBit/s upload and 1 TB storage

Node A will be treated as a "passive" node, and Node B will be treated as an "active" node.

People will want to use Node B because of the faster speed. On the other hand, Node A, has 1 TB of unused storage. So people will upload files to Node B, and Node B will charge for bandwidth and storage. Node B has to maintain file redundancy in case it goes down, so it will buy storage space from Node A, and verify periodically through hashing that Node A is storing the correct data. Node B can also rely on other external services, or another decentralized network such as MaidSafe to physically store the files.

Node's B motive is to approach 100% saturation of its resources. So using Dropbox prices and 3x redundancy, Node B could generate about ~$150 a month. About half of this is from selling its hard drive, the other half is from reserving a small cache space and then shuttling uploaded files to other nodes and networks.

Node A would earn substantially less. It would serve as a very poor shuttle for data. Furthermore because of the low bandwidth, it would be very hard to achieve full saturation of the hard drive.

But wait, we still have a use for Node A. If we could pre-load Node A will files. Let's say tons of small < 100kb files that are slated for long term storage (lets say these are used on a backup application and probably won't really be accessed much at all). Therefore Node A would only have to pass hash verifications, and the occasional file transfer. It can also approach full saturation.

Send me a PM. Let's see what happened.

Just our basic template, there will be many more with different use cases as the project goes on.

To be clear we are only talking about the prototype coins for now. Distribution and algorithm for the Storjcoin will be decided in the future. The prototype coins will allow us to test our applications and algorithms on a live network. That way we can learn and arrive at Storjcoin will working solutions, and values based on on data rather than arbitrary numbers.

"How are you going to distribute the initial coins, if not by proof-of-burn?"
For protocoin(let's just call it that for now) standard genesis address funding, most likely using the Angelshares model. We would rather use the BTC to further development then destroy it. I'm thinking of a very interesting equity and mining distribution. I'll be combining all the models that have seemed to have worked over the few months, and adding some of my own.

"If you do POW like bitcoin, then your inflation rate will be around the same 15% that bitcoin is looking at.
If holding StorJcoins always has 15% inflation, then it wont be very popular as an investment vehicle."
I would counter this point, but I think http://coinmarketcap.com/ speaks for itself. Our prototype coin that we intend to release soon will be your typical altcoin with POW, with a few changes. We can use this immediately in our proof-of-concept decentralized storage web app. I think we will be the first to use blockchain as the basis for a full application. The blockchain will store file metadata, and allow all the web nodes to play nicely.

Keynesian inflation doesn't really apply that well here. While initially there will be a burst of created coins (as with any coin launch), but as the decentralized storage web app is used tx fees for storing metadata are returned to miners. So essentially your block reward could mostly consist of recycled coins through the app. Theoretically, you could destroy the tx fees, or replace the block reward with tx fees. Essentially you could enforce smooth and used defined deflation through use of the currency. Or perhaps the tx fees could be returned to the coin holders as dividends. Possibilities of cool economic models are endless.

I can't think of a single benefit of POW over slasher...
POW works, and can be deployed now. Last time I checked slasher only existed on paper.

If you do not implement these things, then I think I am more excited for alt-StorJcoins than I am for Storjcoins.
I've always thought that altcoins helped innovation(although most are copies). So we take the reverse approach. Alt-Storjcoins are built to get to Storjcoin proper, where we just standardize all the models that worked well.

The interface looks really nice. Purple is a good color.

You said: "No, neither are particularly useful on our case. Our prototype coins + a storage application will be launch very soon." in reference to proof-of-burn for initial distribution of coins, and slasher for ongoing coin distribution.

Do you care to elaborate at all?
How are you going to distribute the initial coins, if not by proof-of-burn?
Giving out free money to whoever happens to own the best hardware on your release date?

If you do POW like bitcoin, then your inflation rate will be around the same 15% that bitcoin is looking at.
If holding StorJcoins always has 15% inflation, then it wont be very popular as an investment vehicle.

What do you think of the concept of "bonds", like US financial bonds that the government sells?
Bonds help stabilize the value of the currency in a huge way.
Slasher-style POS would mimic bonds.

I can't think of a single benefit of POW over slasher...

If you do not implement these things, then I think I am more excited for alt-StorJcoins than I am for Storjcoins.
Any advice on how to fork your project? Should I wait longer for it to get more developed?

Very interesting. There are basically two topics: storage and bandwidth. Sounds like this here uses some kind of "proof of storage" but would you mind to talk a bit about the bandwidth part? Is a node with 56 KBit/s and 1 TB storage treated equal as a note with a 10 MBit/s upload and 1 TB storage?

your mailing list sign up do not work. I signd up but I dont get a confermation mail

Ugh, I want this. I have over 2.5 TB sitting empty on my computer that could be used for this.

Nice little interface upgrade to one of the web nodes:

But that was not by design to raise money for the project. We indeed to release many nodes at launch, but don't believe in not giving everyone a fair chance to use our open source software.

No, neither are particularly useful on our case. Our prototype coins + a storage application will be launch very soon.

I met you at Texas Bitcoin Conference. Your project is so amazing.
Will you be doing proof-of-burn against bitcoin for initial distribution of coins?
Why not use slasher for your blockchain?
http://blog.ethereum.org/2014/01/15/slasher-a-punitive-proof-of-stake-algorithm/
When will I be able to buy StorJcoins?

Is the site not live yet?

What do you mean?  This is pretty close to the bitcoin model.  When Satoshi started running the bitcoin network, who else was mining?  It was just him.  Perhaps "monopoly" was a poor choice of words, call it a "head start".

Because you won't have any benefit from low difficulty like he did, I'm suggesting you have a lot of storage infrastructure ready the day you release.  After that, anyone else will be free to enter, but if it's anything like bitcoin mining, it will take some time before you have any competition.  

The downside, is of course, there's no guarantee you'll have enough customers to get paid before the competition gets online.  That's more of a marketing problem that's outside my area of expertise.

Anyway, it was just an idea, feel free to ignore it if it doesn't suit you.

Wholeheartedly disagree. Would Bitcoin have succeeded if Satoshi followed this model?

I want people to use the node software for many different uses, and expand upon it. If I lock it up and have a monopoly, where is the innovation in that? The competition comes from people improving the base software, and running it themselves.


I agree. Will have to start brainstorming some better branding.

Mostly comes down to code reuse and development time. Why spend a month or two developing a highly available blob store, when you have something that can fill that function already. Scales to millions of files with little bloat. At any time you can replace it with a more efficient method. There are several more reasons why to use an blockchain or alt currency, but we have to be clear if we are discussing technical implementation and efficiency or underlying incentives and other use cases.

Furthermore, blockchain time scale can be very important. I might run a script that checks that the file is still available after x blocks. In that way if a node fails we can replicate the file elsewhere and maintain redundancy. Many more uses of a blockchain other than just a metadata store in this context.

Why should the client do extra work when we can automate that through software?

I've thought about this a bit too, my idea for funding it would be to own most of the nodes at launch.  So the developers start off with a monopoly, and as the the community grows, more competition is added.

Edit: obviously this would work better if you developed privately and then released the code at launch

Proving the time or date that something is uploaded could be useful. So unless there is some other way that a given stored file can have it's date/time of storage reliably proven, a chain of hashes would constitute a good enough proof for most uses. Maybe hash the file and the previous block to get n+1. Would be pretty data light in comparison to the majority of useful filesizes you would typically expect with cloud storage.

I always figured that

• Agents would act as competitive peers in a market.
• User software would communicate with multiple agents, and replicate accordingly.

Of course it need not be this way.

RE chains:  A chain produces a time-ordered sequence of events.  That's not storage and typically you don't need to store actual data in a chain, even if you do need time ordering.  You just store a hash, then the data may be stored and proven as needed in any fashion.  One might imagine software and agents competing to determine the best replication methods at the lowest cost.

Indeed, that is confusing.

But even so, you STILL don't need a block chain or alt currency. Block chains are designed to order database transactions temporally in the presence of malicious re-orderers, which is not a problem you have with encrypted blob storage.

If a client wishes to insulate himself from an agent going away, he can just upload to several. If one dies, pick another and rereplicate. You need a client that can wake up every so often and pay the agents and rereplicate, but that's OK, everyone has smartphones these days and they can easily do that.

Like I noted in private email, I like this project and hope it succeeds...  but calling it "Storj" just generates confusion whenever it differs from the original gmaxwell design.

You really want your own project name, and just give a shout-out to the project genesis:  "Automaton, inspired by StorJ"