Author

Topic: Community Input Please - new Alt Crypto (Read 1131 times)

sr. member
Activity: 403
Merit: 251
February 26, 2013, 12:13:29 PM
#14
key problems


-Choose anonymity level of the project. I think more is better.

 For example, malicious uploaders could try to bring down an auxchain
 by adding files to make hosting illegal in most places.

 Perhaps the network should choose where to store each file/each chunk of data,
 and encrypt it with keys derived from *other* auxchain's hashes. This way you would
 need service of the live network (or at least static copy of considerable part of it)
 to access anything.

-If "downloaders" are not required to connect directly to the "hosters" then all nodes
 between them would want to be paid too for their bandwidth,
 and the "exit node" extra pay for legal risk...

sr. member
Activity: 448
Merit: 250
February 19, 2013, 12:08:45 PM
#13
Hey

Thought i'd take a little time before replying and thinking.

File sizes will be a huge issue here.

Are we expecting people to store the aux chains on their hard drives? Wow that could be a tough problem to solve.

Say there are movies that have been uploaded into the chain.

Curious how the aux chains work if the file sizes of an aux chain > MAX amount?



Possibly, the idea is, not everybody has a copy of all the files.  I guess reward for serving files/chains, and, retaining less-commonly downloaded files equally, but aslong as the host has the full main chain, they can select how many smaller chains to retain also.

Instead of using aux chains you could use a DHT (Distributed Hash Table).

Possibly, but need to think of a way to verify that host x has a full copy of file y, also, the idea of an aux chain may allow the client to download from n hosts, splitting their fee between all n. Still valid idea

 
Thinking crazy here:

Is it possible to use the IP packets for "mining"? The more the aux chain is downloaded (generating IP packets), the more "mining" occur on that aux chain, generating FileCoin for that file provider.

Not really, as IP is too low to verify who sent what, just modifying the header would blow things up.

Obviously the backbone connection and hosting companies can offer bandwidth and storage cheaper than those who they sell it to, but I guess if some of their customers are paying for more than they use they could get some of it back by selling even if they sell "at a loss" since its a loss they otherwise have to eat the whole of anyway.

-MarkM-


I agree, but, the same way the hardware companies could make custom asics.


Anyway, im starting drafting a white paper for this - really would like some input around what to hash/authenticate/key procs s.t. can validate host retains n copies, and only client with key can download file.

legendary
Activity: 2940
Merit: 1090
February 12, 2013, 07:29:50 AM
#12
Obviously the backbone connection and hosting companies can offer bandwidth and storage cheaper than those who they sell it to, but I guess if some of their customers are paying for more than they use they could get some of it back by selling even if they sell "at a loss" since its a loss they otherwise have to eat the whole of anyway.

-MarkM-
legendary
Activity: 1204
Merit: 1002
RUM AND CARROTS: A PIRATE LIFE FOR ME
February 12, 2013, 06:34:58 AM
#11
Thinking crazy here:

Is it possible to use the IP packets for "mining"? The more the aux chain is downloaded (generating IP packets), the more "mining" occur on that aux chain, generating FileCoin for that file provider.

Wouldn't that benefit people with fast connections? And wouldn't that give others the ability to limit your mining ability? IE: if you used Comcast for your internet service, they could slow your IP packets just to purposefully limit your mining? While Comcast itself could mine like crazy because they have a fast connection?
legendary
Activity: 1205
Merit: 1010
February 12, 2013, 02:56:16 AM
#10
Thinking crazy here:

Is it possible to use the IP packets for "mining"? The more the aux chain is downloaded (generating IP packets), the more "mining" occur on that aux chain, generating FileCoin for that file provider.

If you can do that that would be a whole new different kind of 'proof-of-work'. However so far no one has come up with a proof scheme using other resource types.
hero member
Activity: 632
Merit: 500
February 12, 2013, 02:44:35 AM
#9
Thinking crazy here:

Is it possible to use the IP packets for "mining"? The more the aux chain is downloaded (generating IP packets), the more "mining" occur on that aux chain, generating FileCoin for that file provider.
legendary
Activity: 1078
Merit: 1005
February 11, 2013, 05:46:55 PM
#8
Instead of using aux chains you could use a DHT (Distributed Hash Table).
sr. member
Activity: 476
Merit: 253
February 11, 2013, 04:06:01 PM
#7
File sizes will be a huge issue here.

Are we expecting people to store the aux chains on their hard drives? Wow that could be a tough problem to solve.

Say there are movies that have been uploaded into the chain.

Curious how the aux chains work if the file sizes of an aux chain > MAX amount?



file size is not an issue, just like hashpower is not an issue for bitcoin.

make miners get paid only little for mining, and a lot for transfer, and even more for amount of available data - i can assure you thousands of nodes serving terabytes in no-time Smiley

i know peoble that had like 10 harddrives to be able to connect to gigantic DC hubs, just to download stuff, imagine what would they do to make money....  

i can see serving/mining rigs, but not  10 mobo's of 4x 5970 radeons -> 10 mobo's of 10X2tb drives instead.
legendary
Activity: 2492
Merit: 1491
LEALANA Bitcoin Grim Reaper
February 11, 2013, 02:27:58 PM
#6
looks fine. At first place any blockchain is a tool for storing some sort of information. In most cases the infomation is money transactions but it could be any. It's not hard to imagine "FileCoin" where anybody can pay 1 FLC for 10 kb and access it any time in future with guarantee than noone could change or loose it.

But then reward must be both for mining (since miners produce NEW files) and for storing the blockchain (since such people preserve OLD information). Otherwise noone will store. Thus in such a system one will be able to get income from their hard drives. That's interesting.

Interesting thoughts.
legendary
Activity: 1205
Merit: 1010
February 11, 2013, 02:25:08 PM
#5
Files do not need to be in an 'aux chain'. That would complicate things unnecessarily. Gavin once pointed me to his proposal for bitcoin metadata here:
https://gist.github.com/gavinandresen/4073937

Maybe you can do something similar and just drop file (chunks) to a subdirectory in the wallet. The tough job is to balance the storage/availability but as it is a coin so it has the advantage over traditional file sharing networks in that you can hopefully leverage the economics to do the dirty work. My recommendation is that you allow each user to set upload/download fees for his storage, and each node to keep some availability/bandwidth metrics for peers. Then when you search for a file to download you can set a max price and client negotiates the best peers for you. Keeping the download/payment atomic is likely very challenging. Overall I think it's quite an ambitious but interesting project.
member
Activity: 82
Merit: 10
February 11, 2013, 01:46:06 PM
#4
looks fine. At first place any blockchain is a tool for storing some sort of information. In most cases the infomation is money transactions but it could be any. It's not hard to imagine "FileCoin" where anybody can pay 1 FLC for 10 kb and access it any time in future with guarantee than noone could change or loose it.

But then reward must be both for mining (since miners produce NEW files) and for storing the blockchain (since such people preserve OLD information). Otherwise noone will store. Thus in such a system one will be able to get income from their hard drives. That's interesting.
legendary
Activity: 2492
Merit: 1491
LEALANA Bitcoin Grim Reaper
February 11, 2013, 01:18:34 PM
#3
File sizes will be a huge issue here.

Are we expecting people to store the aux chains on their hard drives? Wow that could be a tough problem to solve.

Say there are movies that have been uploaded into the chain.

Curious how the aux chains work if the file sizes of an aux chain > MAX amount?

legendary
Activity: 1420
Merit: 1010
February 11, 2013, 11:43:52 AM
#2
I like the sound oif this alt-coin..... potentially could be used for the storing of say torrent files for people to download... or for whole ebooks and information resources Smiley

I've not been round long enough to know in code what you would have to overcome, but I would be happy to support you with this project in coding, mining, testing and uploading my files to the network Smiley good luck and keep me informed of your progress
sr. member
Activity: 448
Merit: 250
February 11, 2013, 10:58:10 AM
#1
I have been around for a while, and have been pondering creating a new alt crypto currency.  Most of the crypto currencies out there are mostly rehashes/param changing of Bitcoin.  This hopefully should be something different.  I'd like some input on my ideas, and which things I'd need to look at.

It's a distributed file system crypto currency/chain.

Files are stored in aux chains, clients are not expected to host all aux chains.  The network must maintain at least N copies of all aux chains. 

Mining the block chain itself provides reward/currency into the market.

Uploading a file costs an amount
Downloading the file costs an amount

Rewards given to people who keep copies of complete aux chains on their system, and provide accessibility - e.g. some formula after each block where some reward is given based on number of aux chained (would have to be verify-able) and number of downloads, again verifable.

The main chain would include a list of "downloads" of the aux chain/files - e.g. if aux chain n was requested with correct key k from a server identified by some key, then, that key would get a reward during block generation (basically the sum of the "cost" paid by the user to view the file - allows biasing towards serving ppl that pay more). Only the person with the correct "key" for a file can request a download said file.

I'd probably write the app from scratch instead of forking.

Anybody got any input?  Can anybody see any key problems / hurdles i'd need to start looking at?
Jump to: