 Show Posts
|
|
Pages: [1]
|
Alternatively concatenate the timestamp/signature of the last block onto the file contents, and hash that? Would that work?
Yes that will require disk access, but we're assuming that disk rate is faster than network rate.
Interesting, I'll have to think about that. Initial thought was that I don't think so because then how do the other nodes know what the original file contents are. |
|
|
|
I image a kind of free "distributed dropbox" with huge capacity.
Is it possible to use proof of storage for a new coin? It would serve as a free distributed filesystem for people who need extra space. People who have extra space would earn coins.
If its even possible there's probably other ways to do it, but here is my way:
-nodes store segments of a file that someone wants backed up
-for each block, nodes agree on a random file segment in a distributed way.
-nodes retrieve the file segment asked for.
-nodes check that the file segment matches a one-way accumulator (or bloom filter?)
-nodes get coins in proportion to the amount of hard drive space they are contributing
Yep, but you can verify somebody else stores the same data only if you have it already as well. What you do is simple cookie authentication: a: generates a cookie like this: { r: random_bytes , sig: ecc_sign(random_bytes) } b: cookie.r == ecc_verify(cookie.sig), if ok then computes sha256(cookie + data_checked_ + cookie) and sends it to a a: does the same sha256 to verify b does indeed stores the data Imho it's impossible to check somebody owns the data without having it as well - if you have only hash of the data, they could have only the hash too and so on. If you can come up with scheme to actually verify storage w/o having it too, I'd be very interested in how to do that! There's also Bytecoin mentioned on the wiki, but its description was too wague for me. I think one-way-accumulators allow you to verify a bunch of data using a small amount of data. The small data piece is what is stored in the blockchain. I think bloom-filters are similar, but I am not an expert in either. Sure, you can verify authenticity of data (if i understand correctly, this is just glorified merkle tree/blockchain). But how does http://upload.wikimedia.org/wikipedia/commons/8/8c/Hashlink_timestamping.svg actually prevents people just storing the hash of data? The data and the hash would have to be the same size. Or, if you like, the data *is* the hash. Then verification consists of actually sending it. Not too bw efficient indeed  No, you only verify that you have a small segment of the file, so that is the bandwidth requirement. |
|
|
|
I image a kind of free "distributed dropbox" with huge capacity.
Is it possible to use proof of storage for a new coin? It would serve as a free distributed filesystem for people who need extra space. People who have extra space would earn coins.
If its even possible there's probably other ways to do it, but here is my way:
-nodes store segments of a file that someone wants backed up
-for each block, nodes agree on a random file segment in a distributed way.
-nodes retrieve the file segment asked for.
-nodes check that the file segment matches a one-way accumulator (or bloom filter?)
-nodes get coins in proportion to the amount of hard drive space they are contributing
Yep, but you can verify somebody else stores the same data only if you have it already as well. What you do is simple cookie authentication: a: generates a cookie like this: { r: random_bytes , sig: ecc_sign(random_bytes) } b: cookie.r == ecc_verify(cookie.sig), if ok then computes sha256(cookie + data_checked_ + cookie) and sends it to a a: does the same sha256 to verify b does indeed stores the data Imho it's impossible to check somebody owns the data without having it as well - if you have only hash of the data, they could have only the hash too and so on. If you can come up with scheme to actually verify storage w/o having it too, I'd be very interested in how to do that! There's also Bytecoin mentioned on the wiki, but its description was too wague for me. I think one-way-accumulators allow you to verify a bunch of data using a small amount of data. The small data piece is what is stored in the blockchain. I think bloom-filters are similar, but I am not an expert in either. Sure, you can verify authenticity of data (if i understand correctly, this is just glorified merkle tree/blockchain). But how does http://upload.wikimedia.org/wikipedia/commons/8/8c/Hashlink_timestamping.svg actually prevents people just storing the hash of data? The data and the hash would have to be the same size. Or, if you like, the data *is* the hash. |
|
|
|
I image a kind of free "distributed dropbox" with huge capacity.
Is it possible to use proof of storage for a new coin? It would serve as a free distributed filesystem for people who need extra space. People who have extra space would earn coins.
If its even possible there's probably other ways to do it, but here is my way:
-nodes store segments of a file that someone wants backed up
-for each block, nodes agree on a random file segment in a distributed way.
-nodes retrieve the file segment asked for.
-nodes check that the file segment matches a one-way accumulator (or bloom filter?)
-nodes get coins in proportion to the amount of hard drive space they are contributing
Yep, but you can verify somebody else stores the same data only if you have it already as well. What you do is simple cookie authentication: a: generates a cookie like this: { r: random_bytes , sig: ecc_sign(random_bytes) } b: cookie.r == ecc_verify(cookie.sig), if ok then computes sha256(cookie + data_checked_ + cookie) and sends it to a a: does the same sha256 to verify b does indeed stores the data Imho it's impossible to check somebody owns the data without having it as well - if you have only hash of the data, they could have only the hash too and so on. If you can come up with scheme to actually verify storage w/o having it too, I'd be very interested in how to do that! There's also Bytecoin mentioned on the wiki, but its description was too wague for me. I think one-way-accumulators allow you to verify a bunch of data using a small amount of data. The small data piece is what is stored in the blockchain. I think bloom-filters are similar, but I am not an expert in either. |
|
|
|
Sorry, I'm not sure I follow you. The proof of work is retrieving the file piece asked for, so you can't delete file pieces otherwise you won't be able to provide the proof of work and receive your coins. Since random file pieces are asked for, you can't delete any pieces.
An amazing amount of date is stored but rarely fetched. Your approach might not know until too late. Also, it requires needless (slow) network traffic to test. Since I'm supposing your proof-of-stake is related to (number of blocks stored) * (time stored/block). Gaming the system might be to a malicious node's advantage. Ok, I think I follow you. The problem is that malicious nodes might gamble, deleting some file segments to gain more space. Since file segments are rarely validated, the gamble might pay of for a long while. You can't increase the validation rate because you can't bog down the network with tons of traffic. Possible solutions: -invalidate all/most of a nodes coins if they are caught without a requested file segment. -only award coins once an entire file has been validated, but then you need a way to keep track of which segments have been checked. -don't worry about it. If you delete 20% of the data you are supposed to have, its not much space, and for each 10 minute block odds of requesting a delete segment is 20%, so you would be discovered quickly. |
|
|
|
|
Ok seems there was some interest. I'm just working this out now. Since I'm only a bitcoin beginner, I admit this might not pan out.
The block chain is basically just like bitcoin, its the same size. Each block has an accumulator that includes all the file segments stored during a 10 minute interval. Though the size of files stored on the network might be huge, the accumulator is small. In proof of work, nodes validate the hash is a solution of for a block. In proof of storage the nodes validate that the retrieved file segment is in the accumulator of the appropriate block.
jimhsu,
I remember hearing about wuala before. I didn't know they went centralized. Thanks.
Redundancy is an issue as mentioned. But, it seems like you can use any amount of redundancy you want, as long as people are adding storage space to the network.
Also, proof-of-bandwidth would also need to be validated, so maybe there are bandwidth tests in order to join the network. Hadn't thought of bandwidth issues before. But would need to be worked out.
|
|
|
|
The blockchain stores one small number for every file. It is an accumulator which has all the file pieces added to it. To verify file segment storage nodes retrieve the accumulator from the blockchain and check that the file segment is in the accumulator.
That is an interesting concept. Thanks for the reference to a Bloom Filter! The problem I see is that while you know the stored a data. You don't know if that store displaced something else. (They deleted the data afterwords) Would you know on the next store? Does every byte stored need to go through the Bloom Filter each time? Article was TL;DR; (yet) An alternate solution is just to pose a proof-of-storage piece of work. Obviously there would need to be redundant storage of each data block. Just ask each redundant node to re-hash the block using a random seed that you choose. They should all match. Sorry, I'm not sure I follow you. The proof of work is retrieving the file piece asked for, so you can't delete file pieces otherwise you won't be able to provide the proof of work and receive your coins. Since random file pieces are asked for, you can't delete any pieces. |
|
|
|
|
I see validation as:
The blockchain stores one small number for every file. It is an accumulator which has all the file pieces added to it. To verify file segment storage nodes retrieve the accumulator from the blockchain and check that the file segment is in the accumulator.
|
|
|
|
|
I image a kind of free "distributed dropbox" with huge capacity.
Is it possible to use proof of storage for a new coin? It would serve as a free distributed filesystem for people who need extra space. People who have extra space would earn coins.
If its even possible there's probably other ways to do it, but here is my way:
-nodes store segments of a file that someone wants backed up
-for each block, nodes agree on a random file segment in a distributed way.
-nodes retrieve the file segment asked for.
-nodes check that the file segment matches a one-way accumulator (or bloom filter?)
-nodes get coins in proportion to the amount of hard drive space they are contributing
|
|
|
|
|
Can't the difficulty of the challenge be decreased to make it easier to mine blocks? Thus the reward is less but you get the reward more often?
|
|
|
|
|
Ahh, I think I get what you were saying now. But I'm not totally convinced. Have to think about it more.
|
|
|
|
|
I don't understand your second point. Say there is 10 coins which were last valued at $10. Now someone sells a coin on an exchange but it only goes for $0.9 dollars. The software scales the coins in existence so that now there is approximately 11 coins total. 11 coins times $0.9 dollars is still $10. Perhaps I'm missing something.
|
|
|
|
|
It doesn't much matter where the exchange rate comes from. If two exchanges differ by 5% its not going to matter, because stableCoin is only an *approximation* of the dollar. At any one time it may fluctuate by a percent or two. It doesn't jump around spastically. Thats what a governor *does*, it regulates something in a smooth manner and is robust to temporary fluctuations.
|
|
|
|
|
Here is an idea for an alternative coin which is pretty simple. It would be exactly like bitcoin, except that there is a mathematically defined governor, or multiplier, which changes the amount of stableCoin in existence. The amount of coins owned at time i, SC(i), is equal to a multipler k(i) times the previous amount of coins owned SC(i-1). The value of the multiplier is defined in terms of the current stableCoin/USD exchange rate and the desired exchange rate, namely 1:1. The theory of control systems gives the optimal rate of change of the multiplier to avoid wild oscillations but to approach equilibrium quickly. Even if the exchange rate is "noisy" the equations should give a multiplier value that results in a stable value of money. Thus, volatility is decoupled from the coin.
|
|
|
|
|
Can people's spare processor time really compute with custom hardware? How big is there distributed data center?
|
|
|
|
even though hash rates are going up aren't there more transactions per second in the blockchain to be hashed out meaning a zero sum increase or am I missing something in the scheme of it all ?  Yes, you are. The amount of transactions in a block doesn't have an influence on how long it takes to find a hash that is below the current network threshold (difficulty level). I thought what crypto canary was asking is why isn't the span five minutes? What is "optimal" about having it be 10 minutes? |
|
|
|
|
