Sarchar



Offline



Activity: 88

Merit: 10







MemberActivity: 88Merit: 10 [ANNOUNCE] Whitepaper for Bitstorage - a peer to peer, cloud storage network November 27, 2013, 01:33:59 PM #1 Bitstorage - A distributed, peer to peer, cloud data storage network based on blockchain technology.



Whitepaper at



This is just a rough draft, and it heavily depends on coming up with some improvements to the distributed Proof of Data Possession (PDP) strategy, but I believe the incentives are all in the right place.



I intend to start this project over the next few weeks. Feedback welcome.



-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1



$ md5sum Bitstorage.pdf

d5483a62bb3f735a86543d2fb650c67d Bitstorage.pdf



RIPEMD160(SHA256(d5483a62bb3f735a86543d2fb650c67d)) = 883f641127ca05a96224c8c4a937117c287b431f

Bitcoin Address: 1DRQqZmYZeoc4kRE8pjiVq3tn7KqUfBeor



Transaction 52ffd13473d68eb68d48b88dbe259699a75a05a0f1e556d577c127b1da6bfb80





-----BEGIN PGP SIGNATURE-----

Version: GnuPG v1.4.10 (GNU/Linux)



iQEcBAEBAgAGBQJSlfH8AAoJEBSq1Xfbtr1c5s4H/3mmDzva5AzNRFx5ZiYILUrD

x4fXiZvQU1ECFw3e3rZeesSG5OEsZ711OF2pT/J9WyXgW9jsO7WCUgoHDN9nEg+j

H8YM+nYgzwrZrf44cbePbwEnLFthCxNs88PgokEegsWpLP6Xha4o8yBnKuxq7Bj+

yjiQJheWGYpOdWf1rJeFG6/K5j9myULZpfy8txHVUv29pbhA5+fqwDPIzv4wXBob

/14/ZGXgTTVH4r9/t5VOKVXBCEoYVWRL7/2qmpXaHJlJtoxZg2WlMNYa2KDvLDZk

d0edNi2KJTzlQi3BSgTTvSzZm9ylpbGZ424heIyymjeW+i8DjBWyGe7wDiLVpgo=

=qBc0

-----END PGP SIGNATURE-----



-----BEGIN PGP PUBLIC KEY BLOCK-----

Version: GnuPG v1.4.10 (GNU/Linux)



mQENBFKV4jcBCAC3isJW4DG3bsFqvkWorFkGDkX10EtAGOcMy8XzA+jxBim1qgzw

ry2eWNDa4XYozW8g6awQ/lWOpat8NBcnEyscDAAldM6dV/ymJItKZ6TW4alxDdk6

OwrcMp/7qf60j529rcbnXNNwov5lXoqp3IxT/Iqwk7e1IkJt4D80EpbMeFvtH6aB

WV27aWDfBzSjl+JhfAsyLnQRPxfcC4jpUAzXKub5akBS9AgUSApMeub9Q4pXvudY

O4w4Q0i20AQ/EjQNgqbkDj7L+QXFh17P8k1ojH1a7bNAdpqjDNR7gR3b/paJzi8U

Y+LLHet20/RXORJ99ApfDh5NzOSegWULBYfZABEBAAG0G1NhcmNoYXIgPHNhcmNo

YXJAbG9jYWxob3N0PokBPgQTAQIAKAUCUpXiNwIbAwUJCWYBgAYLCQgHAwIGFQgC

CQoLBBYCAwECHgECF4AACgkQFKrVd9u2vVwuKwgAptl7NkiFFDfXpjjWadZIVJUv

AXAnjr5yI3BUCpquAXauOtS3lwfi+yvCDmOIPkSq4+yQxA8q6JyQxKPsYDo4M84i

DaPjpo0uyryU4aKB1rpnVQoUY/KQQgX4kSLGrxzq6lV8O2EycmRk0Lss1zc1nYx8

g6nNiUZRrgs1kLdnCFIF5aRwq+ChIslpm9bCd2O+lALTp9FRY1nVgHgrs0J3ut7v

ZOxsHFvcGw/MfHFambTR+u+X6ib7zn3o8LCy4BUb+2bQF253Tx4ze+Xa1e3g/jCo

5AYXzaLbJxjSFyOO8A/M2GYJCMbIbSQuw9zr6/IaT0fUm5H5UriagVxMI9yuHLkB

DQRSleI3AQgAyBcA+D7DEAwDIKYfH569tDINWuIQcGBaMgteaxX4DBIGmCt0gC/Z

qEtJP8V1o1RQAgA5ks/v7YzmINyLYUMB4WI6FyrLVldL8adPg7KAx3iqAZVGHTol

6j21Wi8poB8c1m3aYx21M9aJOzAcF3nuZk/9pHz+G+Gk9NJVvD1/CyHLl8qB8jb3

nIDYfQeaeSqotEZvaqwkDy1RdnxDlyj9AUePubGXhFfAMycRSuhh7qdNyqWiEgu0

1YydxXc+m8fiF+klHy6DQeeIMg0SzUpLab5brMDNkft0O7rVjgZcXKf+e9uCBDuo

G3YKAAxqnV5H2jy8LrjFOvTmjT5SseqwZQARAQABiQElBBgBAgAPBQJSleI3AhsM

BQkJZgGAAAoJEBSq1Xfbtr1cmEAH/j0Obtzb+AokpkfdAJx5fdn6cg1yivXSIpke

qbYkeeVa7Udm3v1CTFvlQczSLvRX8d8JD618ZZS/rConsFVvMEcdlBB41kTbg/Xu

aR2BoK/5mlWF2o/f2M/zaqleG4EAY6MyJd0AkIwNePT402jCqGloXLamgLNyE0lv

v4wjP0nV2H4fy5rf55SIjduLRMLYUXlhftGNUxn3L40qtuzZ0XXPHbNL7IVL1Sca

UqA4opv906X3EaLOlr4pTspFYeWknGOnLmwH7pBehqYLBlmLoMP6E1hSiXxuXpp7

srhYUnILkvMXciVK/FBQKa6goJ+VrJfzm9R/bhDhoPZ5S3Tm5gM=

=U9o1

-----END PGP PUBLIC KEY BLOCK-----



- A distributed, peer to peer, cloud data storage network based on blockchain technology.Whitepaper at http://dropcanvas.com/m942t This is just a rough draft, and it heavily depends on coming up with some improvements to the distributed Proof of Data Possession (PDP) strategy, but I believe the incentives are all in the right place.I intend to start this project over the next few weeks. Feedback welcome.-----BEGIN PGP SIGNED MESSAGE-----Hash: SHA1$ md5sum Bitstorage.pdfd5483a62bb3f735a86543d2fb650c67d Bitstorage.pdfRIPEMD160(SHA256(d5483a62bb3f735a86543d2fb650c67d)) = 883f641127ca05a96224c8c4a937117c287b431fBitcoin Address: 1DRQqZmYZeoc4kRE8pjiVq3tn7KqUfBeorTransaction 52ffd13473d68eb68d48b88dbe259699a75a05a0f1e556d577c127b1da6bfb80-----BEGIN PGP SIGNATURE-----Version: GnuPG v1.4.10 (GNU/Linux)iQEcBAEBAgAGBQJSlfH8AAoJEBSq1Xfbtr1c5s4H/3mmDzva5AzNRFx5ZiYILUrDx4fXiZvQU1ECFw3e3rZeesSG5OEsZ711OF2pT/J9WyXgW9jsO7WCUgoHDN9nEg+jH8YM+nYgzwrZrf44cbePbwEnLFthCxNs88PgokEegsWpLP6Xha4o8yBnKuxq7Bj+yjiQJheWGYpOdWf1rJeFG6/K5j9myULZpfy8txHVUv29pbhA5+fqwDPIzv4wXBob/14/ZGXgTTVH4r9/t5VOKVXBCEoYVWRL7/2qmpXaHJlJtoxZg2WlMNYa2KDvLDZkd0edNi2KJTzlQi3BSgTTvSzZm9ylpbGZ424heIyymjeW+i8DjBWyGe7wDiLVpgo==qBc0-----END PGP SIGNATURE----------BEGIN PGP PUBLIC KEY BLOCK-----Version: GnuPG v1.4.10 (GNU/Linux)mQENBFKV4jcBCAC3isJW4DG3bsFqvkWorFkGDkX10EtAGOcMy8XzA+jxBim1qgzwry2eWNDa4XYozW8g6awQ/lWOpat8NBcnEyscDAAldM6dV/ymJItKZ6TW4alxDdk6OwrcMp/7qf60j529rcbnXNNwov5lXoqp3IxT/Iqwk7e1IkJt4D80EpbMeFvtH6aBWV27aWDfBzSjl+JhfAsyLnQRPxfcC4jpUAzXKub5akBS9AgUSApMeub9Q4pXvudYO4w4Q0i20AQ/EjQNgqbkDj7L+QXFh17P8k1ojH1a7bNAdpqjDNR7gR3b/paJzi8UY+LLHet20/RXORJ99ApfDh5NzOSegWULBYfZABEBAAG0G1NhcmNoYXIgPHNhcmNoYXJAbG9jYWxob3N0PokBPgQTAQIAKAUCUpXiNwIbAwUJCWYBgAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQFKrVd9u2vVwuKwgAptl7NkiFFDfXpjjWadZIVJUvAXAnjr5yI3BUCpquAXauOtS3lwfi+yvCDmOIPkSq4+yQxA8q6JyQxKPsYDo4M84iDaPjpo0uyryU4aKB1rpnVQoUY/KQQgX4kSLGrxzq6lV8O2EycmRk0Lss1zc1nYx8g6nNiUZRrgs1kLdnCFIF5aRwq+ChIslpm9bCd2O+lALTp9FRY1nVgHgrs0J3ut7vZOxsHFvcGw/MfHFambTR+u+X6ib7zn3o8LCy4BUb+2bQF253Tx4ze+Xa1e3g/jCo5AYXzaLbJxjSFyOO8A/M2GYJCMbIbSQuw9zr6/IaT0fUm5H5UriagVxMI9yuHLkBDQRSleI3AQgAyBcA+D7DEAwDIKYfH569tDINWuIQcGBaMgteaxX4DBIGmCt0gC/ZqEtJP8V1o1RQAgA5ks/v7YzmINyLYUMB4WI6FyrLVldL8adPg7KAx3iqAZVGHTol6j21Wi8poB8c1m3aYx21M9aJOzAcF3nuZk/9pHz+G+Gk9NJVvD1/CyHLl8qB8jb3nIDYfQeaeSqotEZvaqwkDy1RdnxDlyj9AUePubGXhFfAMycRSuhh7qdNyqWiEgu01YydxXc+m8fiF+klHy6DQeeIMg0SzUpLab5brMDNkft0O7rVjgZcXKf+e9uCBDuoG3YKAAxqnV5H2jy8LrjFOvTmjT5SseqwZQARAQABiQElBBgBAgAPBQJSleI3AhsMBQkJZgGAAAoJEBSq1Xfbtr1cmEAH/j0Obtzb+AokpkfdAJx5fdn6cg1yivXSIpkeqbYkeeVa7Udm3v1CTFvlQczSLvRX8d8JD618ZZS/rConsFVvMEcdlBB41kTbg/XuaR2BoK/5mlWF2o/f2M/zaqleG4EAY6MyJd0AkIwNePT402jCqGloXLamgLNyE0lvv4wjP0nV2H4fy5rf55SIjduLRMLYUXlhftGNUxn3L40qtuzZ0XXPHbNL7IVL1ScaUqA4opv906X3EaLOlr4pTspFYeWknGOnLmwH7pBehqYLBlmLoMP6E1hSiXxuXpp7srhYUnILkvMXciVK/FBQKa6goJ+VrJfzm9R/bhDhoPZ5S3Tm5gM==U9o1-----END PGP PUBLIC KEY BLOCK-----

AWARD-WINNING

CASINO CRYPTO EXCLUSIVE

CLUBHOUSE 1500+

GAMES 2 MIN

CASH-OUTS 24/7

SUPPORT 100s OF

FREE SPINS PLAY NOW dvertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. dvertised sites are not endorsed by the BitcoinForum. Theymay be unsafe, untrustworthy, orillegal in your jurisdiction. Advertise here.

maraoz



Offline



Activity: 56

Merit: 0









NewbieActivity: 56Merit: 0 Re: [ANNOUNCE] Whitepaper for Bitstorage - a peer to peer, cloud storage network November 27, 2013, 03:47:25 PM #2



I may have some thoughts/ideas to contribute, and I'm interested in contributing code to the project, if you need help



Here's what I wrote as an intro to my paper:



Since the creation of Bitcoin [1] a number of technologies leveraged its technical capabilities to create distributed systems for other purposes. Conceptually, blockchain technology allows a network of peers to arrive to an agreement on timestamps for data without the need of a central authority. This has given rise to other applications like alternate cryptocurrencies [2][6], or a distributed messaging system [5].

There is currently a need for a system which allows distributed and reliable storage of documents in the cloud, in a fully decentralized way. Many similar solutions have been proposed, but each have its disadvantages, like being proprietary, needing each user to provide her own storage [3], or not giving incentives to peers to share their storage and bandwidth [7][4].

A blockchain technology based protocol is proposed, which allows the creation of a true cloud in which peers can store their files in other peers' computers. A cryptocurrency tied to the protocol operations makes it possible for people to share their hard drive storage and receive value, or instead pay to have their files stored. The average user will share their local storage space in exchange for storage in the network. No trust in third parties is required, which provides both the benefit of resistance to censorship and protection from prying eyes or companies handing your data to powerful parties via coercion. On the other hand, peers with available and unused storage space can offer their resources into the network to earn value over time in the form of a cryptocurrency. With bucketchain, the more storage space you share to the network, the more mining efficiency your node gets, thus providing the needed incentive for peers to contribute.





Sounds similar? Can we collaborate? BTW, I like your name better





[1] S. Nakamoto., Bitcoin: A Peer-to-Peer Electronic Cash System,

[2] S. King & S. Nadal, PPCoin: Peer-to-Peer Crypto-Currency with Proof-of-Stake2012

[3] BitTorrent Labs, Automatically sync files via secure, distributed technology.,

[4] GNU, GNU's Framework for Secure Peer-to-Peer Networking,

[5] J. Warren, Bitmessage: A Peer‐to‐Peer Message Authentication and Delivery System ,

[6] C. Lee,

[7] B. Cohen, BitTorrent is a protocol for distributing files,



Wow. I've been working for the past months on a very similar concept, which I named BucketChain . I started discussing the idea with friends and colleagues after developing http://www.proofofexistence.com/ , as the next step in filesystem decentralization.I may have some thoughts/ideas to contribute, and I'm interested in contributing code to the project, if you need helpHere's what I wrote as an intro to my paper:Since the creation of Bitcoin [1] a number of technologies leveraged its technical capabilities to create distributed systems for other purposes. Conceptually, blockchain technology allows a network of peers to arrive to an agreement on timestamps for data without the need of a central authority. This has given rise to other applications like alternate cryptocurrencies [2][6], or a distributed messaging system [5].There is currently a need for a system which allows distributed and reliable storage of documents in the cloud, in a fully decentralized way. Many similar solutions have been proposed, but each have its disadvantages, like being proprietary, needing each user to provide her own storage [3], or not giving incentives to peers to share their storage and bandwidth [7][4].A blockchain technology based protocol is proposed, which allows the creation of a true cloud in which peers can store their files in other peers' computers. A cryptocurrency tied to the protocol operations makes it possible for people to share their hard drive storage and receive value, or instead pay to have their files stored. The average user will share their local storage space in exchange for storage in the network. No trust in third parties is required, which provides both the benefit of resistance to censorship and protection from prying eyes or companies handing your data to powerful parties via coercion. On the other hand, peers with available and unused storage space can offer their resources into the network to earn value over time in the form of a cryptocurrency. With bucketchain, the more storage space you share to the network, the more mining efficiency your node gets, thus providing the needed incentive for peers to contribute.Sounds similar? Can we collaborate? BTW, I like your name better[1] S. Nakamoto., Bitcoin: A Peer-to-Peer Electronic Cash System, http://bitcoin.org/bitcoin.pdf , 2008[2] S. King & S. Nadal, PPCoin: Peer-to-Peer Crypto-Currency with Proof-of-Stake2012[3] BitTorrent Labs, Automatically sync files via secure, distributed technology., http://labs.bittorrent.com/experiments/sync.html , 2013.[4] GNU, GNU's Framework for Secure Peer-to-Peer Networking, https://gnunet.org/ , 2013.[5] J. Warren, Bitmessage: A Peer‐to‐Peer Message Authentication and Delivery System , https://bitmessage.org/bitmessage.pdf , 2012[6] C. Lee, https://litecoin.org/ , 2011[7] B. Cohen, BitTorrent is a protocol for distributing files, http://www.bittorrent.org/beps/bep_0003.html , 2008

Mike Hearn



Offline



Activity: 1526

Merit: 1008







LegendaryActivity: 1526Merit: 1008 Re: [ANNOUNCE] Whitepaper for Bitstorage - a peer to peer, cloud storage network November 27, 2013, 04:22:11 PM #3



Very cool stuff. I just wanted to say hi and point out that myself and Simon de la Rouviere have been implementing something a bit like this for a while, but not as ambitious or complex. We're very much about building something up one brick at a time rather than aiming for the stars right from day 1.



We start with the foundation of micropayment channels, and paying for bandwidth to download files. You can see a



Once there are servers that can charge users for downloads, the next step is to allow uploads of data and micropayments for proof of storage. I'm thinking that a client can calculate a series of hash challenges and each time the server passes a hash challenge, the client increments the micropayment channel. An Android app would be ideal for this because it's typically always on and nearly always connected to the internet, so waking up at night every few days to check the files are still there and make a payment is quite straightforward. Also, we've done some work on exposing micropayment channels via a local RPC interface to the Bitcoin Wallet app, so an app that wishes to use micropayments on Android doesn't have to manage their own wallet. The main wallet app grants permissions over subsets of the users balance to individual apps.



Once you can upload, download and store files on a specific server for micropayments, the next obvious leap is to join the servers together in a simple broadcast/advertisement network. Not really a full blown DHT but just a way to find servers that are advertising their services (this is the "TradeNet" for anyone who saw my talk in Edinburgh). Then clients can seek out the cheapest/best servers and start using them.



All this is very complicated because it has to be done in a low trust manner. For instance, a malicious server could advertise the lowest price possible and just attract all the business, and there are various subtle knife-edges in micropayments, like transaction malleability attacks, that require changes on the Bitcoin side.



But overall I think it's simpler than an entirely new block chain and P2P network, and it has the advantage that every few months or so you could release an actually useful piece of software and build up your userbase slowly.



Get in touch with simondlr on this forum if you're interested in taking part. He'll be on vacation for a couple of weeks though soon. I don't anticipate much more coding on this until the new year. Hey there!Very cool stuff. I just wanted to say hi and point out that myself and Simon de la Rouviere have been implementing something a bit like this for a while, but not as ambitious or complex. We're very much about building something up one brick at a time rather than aiming for the stars right from day 1.We start with the foundation of micropayment channels, and paying for bandwidth to download files. You can see a video of the app in action . It's still got a few bugs and other issues to resolve before it's released for regular users, but it's real code and it works. You can view the source here Once there are servers that can charge users for downloads, the next step is to allow uploads of data and micropayments for proof of storage. I'm thinking that a client can calculate a series of hash challenges and each time the server passes a hash challenge, the client increments the micropayment channel. An Android app would be ideal for this because it's typically always on and nearly always connected to the internet, so waking up at night every few days to check the files are still there and make a payment is quite straightforward. Also, we've done some work on exposing micropayment channels via a local RPC interface to the Bitcoin Wallet app, so an app that wishes to use micropayments on Android doesn't have to manage their own wallet. The main wallet app grants permissions over subsets of the users balance to individual apps.Once you can upload, download and store files on a specific server for micropayments, the next obvious leap is to join the servers together in a simple broadcast/advertisement network. Not really a full blown DHT but just a way to find servers that are advertising their services (this is the "TradeNet" for anyone who saw my talk in Edinburgh). Then clients can seek out the cheapest/best servers and start using them.All this is very complicated because it has to be done in a low trust manner. For instance, a malicious server could advertise the lowest price possible and just attract all the business, and there are various subtle knife-edges in micropayments, like transaction malleability attacks, that require changes on the Bitcoin side.But overall I think it's simpler than an entirely new block chain and P2P network, and it has the advantage that every few months or so you could release an actually useful piece of software and build up your userbase slowly.Get in touch with simondlr on this forum if you're interested in taking part. He'll be on vacation for a couple of weeks though soon. I don't anticipate much more coding on this until the new year.

Sarchar



Offline



Activity: 88

Merit: 10







MemberActivity: 88Merit: 10 Re: [ANNOUNCE] Whitepaper for Bitstorage - a peer to peer, cloud storage network November 27, 2013, 04:35:31 PM #4 Quote from: maraoz on November 27, 2013, 03:47:25 PM

Sounds similar? Can we collaborate? BTW, I like your name better

Well, your writing is much nicer than mine, so I appreciate that. I'd be interested in seeing more how your system works. Can you share some documents?



Quote from: Mike Hearn Very cool stuff. I just wanted to say hi and point out that myself and Simon de la Rouviere have been implementing something a bit like this for a while, but not as ambitious or complex. We're very much about building something up one brick at a time rather than aiming for the stars right from day 1.



That's probably the best way to do it, building piece by piece, I mean. I checked out your video and it's cool, but it has its limited usages (peer to peer micropayments is a freaking cool thing). Does it work or can it be adopted for things like public WiFi usage?



How would you accomplish the proof of storage challenge if the original author of the data isn't available online to challenge (or the user loses his metadata required to produce those challenges)? I think part of the strategy that I'd like to see a distributed approach take is for the "blockchain" to be the source of the proof of possession challenges. The randomness of block hashes would be the seed of the challenge algorithm and miners would verify those challenges and receive payment in a coinbase for doing so.



Is your TradeNet talk available somewhere?



Well, your writing is much nicer than mine, so I appreciate that. I'd be interested in seeing more how your system works. Can you share some documents?That's probably the best way to do it, building piece by piece, I mean. I checked out your video and it's cool, but it has its limited usages (peer to peer micropayments is a freaking cool thing). Does it work or can it be adopted for things like public WiFi usage?How would you accomplish the proof of storage challenge if the original author of the data isn't available online to challenge (or the user loses his metadata required to produce those challenges)? I think part of the strategy that I'd like to see a distributed approach take is for the "blockchain" to be the source of the proof of possession challenges. The randomness of block hashes would be the seed of the challenge algorithm and miners would verify those challenges and receive payment in a coinbase for doing so.Is your TradeNet talk available somewhere?

jspilman



Offline



Activity: 19

Merit: 0







NewbieActivity: 19Merit: 0 Re: [ANNOUNCE] Whitepaper for Bitstorage - a peer to peer, cloud storage network November 27, 2013, 04:51:00 PM #5 Is there some mechanism for preventing a single node storing a single copy of the data, and then spoofing multiple identities and claiming payment as-if the data were stored across multiple nodes?



The obvious solutions are proof-of-work or proof-of-stake, but I can't see how proof-of-work alone would suffice.



If the expected cost of performing the proof-of-work is greater than the reward for storing the block, then no one stores it. Otherwise, what's to stop an attacker from generating multiple possession-txs in order to claim all the available payments for a given storereq-tx?



Proof-of-stake would at least provide some capital reserve to allocate to each identity, then you could add a field for minimum proof-of-stake amount into the storereq-tx, and/or you could use it as an ordering criteria instead of the Kademlia distance.





Sarchar



Offline



Activity: 88

Merit: 10







MemberActivity: 88Merit: 10 Re: [ANNOUNCE] Whitepaper for Bitstorage - a peer to peer, cloud storage network November 27, 2013, 05:01:19 PM #7 Quote from: jspilman on November 27, 2013, 04:51:00 PM Is there some mechanism for preventing a single node storing a single copy of the data, and then spoofing multiple identities and claiming payment as-if the data were stored across multiple nodes?



No and yes, that's kind of the point though. If miners are honest and pick only the N closest nodes (using the Kademlia distance metric), then there's high chance that the data will be distributed amongst at least >1 nodes. The more requested nodes in the storereq-tx the greater the chance the data is actually distributed. Metrics that show how dense the identities around your data are can give you an indicator of how likely it is that multiple nodes store the data instead of just a few. The more nodes you're willing to pay to store your data, the more secure your data is.



Quote The obvious solutions are proof-of-work or proof-of-stake, but I can't see how proof-of-work alone would suffice.



If the expected cost of performing the proof-of-work is greater than the reward for storing the block, then no one stores it. Otherwise, what's to stop an attacker from generating multiple possession-txs in order to claim all the available payments for a given storereq-tx?



I imagine they would try, but like I said earlier, payments should go to only the closest nodes to data. As the network grows, there will be too many identities that trying to get closer to a given data block wouldn't be worth it when you can just store some other data that you are actually close to. Managing a lot of identities and data blocks quickly becomes an exponential problem.



Quote Proof-of-stake would at least provide some capital reserve to allocate to each identity, then you could add a field for minimum proof-of-stake amount into the storereq-tx, and/or you could use it as an ordering criteria instead of the Kademlia distance.



I will look into it, and TBH I haven't considered proof of stake for this. Sounds intriguing.

No and yes, that's kind of the point though. If miners are honest and pick only the N closest nodes (using the Kademlia distance metric), then there's high chance that the data will be distributed amongst at least >1 nodes. The more requested nodes in the storereq-tx the greater the chance the data is actually distributed. Metrics that show how dense the identities around your data are can give you an indicator of how likely it is that multiple nodes store the data instead of just a few. The more nodes you're willing to pay to store your data, the more secure your data is.I imagine they would try, but like I said earlier, paymentsgo to only the closest nodes to data. As the network grows, there will be too many identities that trying to get closer to a given data block wouldn't be worth it when you can just store some other data that you are actually close to. Managing a lot of identities and data blocks quickly becomes an exponential problem.I will look into it, and TBH I haven't considered proof of stake for this. Sounds intriguing.

Mike Hearn



Offline



Activity: 1526

Merit: 1008







LegendaryActivity: 1526Merit: 1008 Re: [ANNOUNCE] Whitepaper for Bitstorage - a peer to peer, cloud storage network November 27, 2013, 05:14:35 PM #11 Quote from: Sarchar on November 27, 2013, 04:35:31 PM That's probably the best way to do it, building piece by piece, I mean. I checked out your video and it's cool, but it has its limited usages (peer to peer micropayments is a freaking cool thing). Does it work or can it be adopted for things like public WiFi usage?



It's a general framework. Yes, paying for wifi access is possible (more possible than you might imagine).



Quote How would you accomplish the proof of storage challenge if the original author of the data isn't available online to challenge (or the user loses his metadata required to produce those challenges)?



If the challenge metadata is stored in the same place as the micropayment channels, you either lose both or neither. I think that's solvable. The challenges don't have to be big. If you want 1000 days worth of storage, store 1000 80-bit hashes and you're done, right? 10kb of data is trivial.



Quote Is your TradeNet talk available somewhere?



Yep, see the top video and slide deck beneath it here:



http://plan99.net/~mike/



(unfortunately, the slides in the video are hard to see and washed out) It's a general framework. Yes, paying for wifi access is possible (more possible than you might imagine).If the challenge metadata is stored in the same place as the micropayment channels, you either lose both or neither. I think that's solvable. The challenges don't have to be big. If you want 1000 days worth of storage, store 1000 80-bit hashes and you're done, right? 10kb of data is trivial.Yep, see the top video and slide deck beneath it here:(unfortunately, the slides in the video are hard to see and washed out)

Sarchar



Offline



Activity: 88

Merit: 10







MemberActivity: 88Merit: 10 Re: [ANNOUNCE] Whitepaper for Bitstorage - a peer to peer, cloud storage network November 27, 2013, 05:33:27 PM #12 Quote from: Mike Hearn on November 27, 2013, 05:14:35 PM Quote from: Sarchar on November 27, 2013, 04:35:31 PM That's probably the best way to do it, building piece by piece, I mean. I checked out your video and it's cool, but it has its limited usages (peer to peer micropayments is a freaking cool thing). Does it work or can it be adopted for things like public WiFi usage?



It's a general framework. Yes, paying for wifi access is possible (more possible than you might imagine).

It's a general framework. Yes, paying for wifi access is possible (more possible than you might imagine).



Quote Quote How would you accomplish the proof of storage challenge if the original author of the data isn't available online to challenge (or the user loses his metadata required to produce those challenges)?



If the challenge metadata is stored in the same place as the micropayment channels, you either lose both or neither. I think that's solvable. The challenges don't have to be big. If you want 1000 days worth of storage, store 1000 80-bit hashes and you're done, right? 10kb of data is trivial.

If the challenge metadata is stored in the same place as the micropayment channels, you either lose both or neither. I think that's solvable. The challenges don't have to be big. If you want 1000 days worth of storage, store 1000 80-bit hashes and you're done, right? 10kb of data is trivial.

I think that would be a problem in a distributed environment with terabytes of data meant to be stored indefinitely. The paper linked in my document describes a crypto method that allows for infinite challenges with O(1) metadata storage requirements less than a few kb in size. That metadata can easily be stored in a blockchain.



Quote Quote Is your TradeNet talk available somewhere?



Yep, see the top video and slide deck beneath it here:



http://plan99.net/~mike/



(unfortunately, the slides in the video are hard to see and washed out)

Yep, see the top video and slide deck beneath it here:(unfortunately, the slides in the video are hard to see and washed out)

Thanks. Cool. I'm going to look more into this project.I think that would be a problem in a distributed environment with terabytes of data meant to be stored indefinitely. The paper linked in my document describes a crypto method that allows for infinite challenges with O(1) metadata storage requirements less than a few kb in size. That metadata can easily be stored in a blockchain.Thanks.

Peter Todd



Offline



Activity: 1106

Merit: 1045







LegendaryActivity: 1106Merit: 1045 Re: [ANNOUNCE] Whitepaper for Bitstorage - a peer to peer, cloud storage network November 27, 2013, 05:47:56 PM #14 Quote from: jspilman on November 27, 2013, 04:51:00 PM Is there some mechanism for preventing a single node storing a single copy of the data, and then spoofing multiple identities and claiming payment as-if the data were stored across multiple nodes?



That's impossible unfortunately - no amount of math can prevent a node from outsourcing the actual storage to a central location that is a single-point-of-failure.



The best you'll ever be able to do is pay enough that there is incentive to do the job right, and/or use social/legal mechanisms to audit what node operators do and then arrange these transactions with specific operators. Not terribly exciting solutions unfortunately...



Quote from: jspilman on November 27, 2013, 04:51:00 PM The obvious solutions are proof-of-work or proof-of-stake, but I can't see how proof-of-work alone would suffice.



Yeah, proof-of-work can only prove IO bandwidth, not where the data is located.



However... interactive latency measurements can prove data within some sphere of radius t*c. With multiple trusted challenge servers around the world located in co-location centers one could easily prove that the data must be physically present in multiple locations.





You can even do in a fully decentralized way with some extensions to the Bitcoin scripting language by creating a txout that can only be spent by proving you have some data fragment, where the fragment is chosen randomly based on the previous block hash.



Because the fragment is based on the previous block hash, there is a time limit to how quickly the fragment must be retrieved, thereby proving (after sufficient trials) that the data is physically located within a sphere of radius 10minutes * the speed of light - currently this would prove the data may be physically located on Earth, the Moon and Venus, but no other planet. With a second proof-of-work blockchain established on, say, Pluto, we could then easily prove a similar result for data located on or nearby Pluto. (proving the Pluto proof-of-work blockchain is in fact located on Pluto is left as an exercise for the reader) That's impossible unfortunately - no amount of math can prevent a node from outsourcing the actual storage to a central location that is a single-point-of-failure.The best you'll ever be able to do is pay enough that there is incentive to do the job right, and/or use social/legal mechanisms to audit what node operators do and then arrange these transactions with specific operators. Not terribly exciting solutions unfortunately...Yeah, proof-of-work can only prove IO bandwidth, not where the data is located.However... interactive latency measurementsprove data within some sphere of radius t*c. With multiple trusted challenge servers around the world located in co-location centers one could easily prove that the data must be physically present in multiple locations.You can even do in a fully decentralized way with some extensions to the Bitcoin scripting language by creating a txout that can only be spent by proving you have some data fragment, where the fragment is chosen randomly based on the previous block hash.Because the fragment is based on the previous block hash, there is a time limit to how quickly the fragment must be retrieved, thereby proving (after sufficient trials) that the data is physically located within a sphere of radius 10minutes * the speed of light - currently this would prove the data may be physically located on Earth, the Moon and Venus, but no other planet. With a second proof-of-work blockchain established on, say, Pluto, we could then easily prove a similar result for data located on or nearby Pluto. (proving the Pluto proof-of-work blockchain is in fact located on Pluto is left as an exercise for the reader) BTC: 1FCYd7j4CThTMzts78rh6iQJLBRGPW9fWv PGP: 7FAB114267E4FA04

jspilman



Offline



Activity: 19

Merit: 0







NewbieActivity: 19Merit: 0 Re: [ANNOUNCE] Whitepaper for Bitstorage - a peer to peer, cloud storage network November 27, 2013, 06:19:59 PM #15 Quote from: Peter Todd on November 27, 2013, 05:47:56 PM Because the fragment is based on the previous block hash, there is a time limit to how quickly the fragment must be retrieved, thereby proving (after sufficient trials) that the data is physically located within a sphere of radius 10minutes * the speed of light - currently this would prove the data may be physically located on Earth, the Moon and Venus, but no other planet. With a second proof-of-work blockchain established on, say, Pluto, we could then easily prove a similar result for data located on or nearby Pluto. (proving the Pluto proof-of-work blockchain is in fact located on Pluto is left as an exercise for the reader)



I suppose the proof of work could take the previous block hash along with some nonce and then iterate on the data in a 'memory-hard' fashion to add latency. Each nonce+result would be redeemable for a single payment coupon within some fixed time period, e.g. when the next block is found.



I think a good solution to this problem is useful in all sorts of interesting ways... for example, when the blockchain itself is the target data, and the storage payments are transaction fees. I suppose the proof of work could take the previous block hash along with some nonce and then iterate on the data in a 'memory-hard' fashion to add latency. Each nonce+result would be redeemable for a single payment coupon within some fixed time period, e.g. when the next block is found.I think a good solution to this problem is useful in all sorts of interesting ways... for example, when the blockchain itself is the target data, and the storage payments are transaction fees.

Mike Hearn



Offline



Activity: 1526

Merit: 1008







LegendaryActivity: 1526Merit: 1008 Re: [ANNOUNCE] Whitepaper for Bitstorage - a peer to peer, cloud storage network November 27, 2013, 08:43:50 PM #16 The E-PDP paper is interesting but my reading of it was different to yours - their sample had to store 128mb of tags for a 4g file. It doesn't have the small overhead you think: it reduces client overhead by increasing server overhead. It's also more intensive - randomized hash challenges boil down to one disk seek on the server (in the best case of an unfragmented file) and some hashing which is fast, whereas their scheme involves lots of hopping around.



Still, I think it's not a huge difference. You could implement v1 using a simpler proof of storage and then upgrade to more complex proofs in a v2.

mappum



Offline



Activity: 82

Merit: 10







MemberActivity: 82Merit: 10 Re: [ANNOUNCE] Whitepaper for Bitstorage - a peer to peer, cloud storage network November 27, 2013, 08:47:32 PM #17 It all looks pretty solid, I've only come up with a few small issues.



First of all, I don't think there is a need to limit the downloads to nodes that are close and the owner. This prevents use as a CDN, and also, it is trivial to keep generating new private keys until one is found that is close to the desired file.



Also, (this may or may not be a problem) as mentioned in IRC, attackers could also keep changing their data to change its hash to decide what nodes they want to store it.



A bigger problem is that infinite nodes can be hosting the same data while the owner will only pay out to n nodes. The nodes that get to be paid are simply the ones who announce it first, and any attacker can just keep announcing the data they have (unless all nodes are recording all announcements). This could add up to be a lot of data. Even with no attackers, it means potential income isn't guaranteed, and you will lose a lot of it from the bad luck of not being first.

Sarchar



Offline



Activity: 88

Merit: 10







MemberActivity: 88Merit: 10 Re: [ANNOUNCE] Whitepaper for Bitstorage - a peer to peer, cloud storage network November 29, 2013, 05:34:45 AM #18 Quote from: Mike Hearn on November 27, 2013, 08:43:50 PM The E-PDP paper is interesting but my reading of it was different to yours - their sample had to store 128mb of tags for a 4g file. It doesn't have the small overhead you think: it reduces client overhead by increasing server overhead. It's also more intensive - randomized hash challenges boil down to one disk seek on the server (in the best case of an unfragmented file) and some hashing which is fast, whereas their scheme involves lots of hopping around.



Still, I think it's not a huge difference. You could implement v1 using a simpler proof of storage and then upgrade to more complex proofs in a v2.



Kinda, yeah. I think in a distributed network, using larger blocks than 4KB (say 32KB) would be much better. I had envisioned each store request supposed to be less than 1MB in size, so with a 1024-bit modulus that would require 4096 bytes of extra storage. Increasing the message size to 128KB means only 1Kb extra storage. Unfortunately, that's data that has go to go into the blockchain. It'd be nice if there was a better way that allowed for smaller storage + infinite challenges.



Are my numbers right, here?



Definitely, the best way would be to develop this in steps, and the first step would definitely not implement the E-PDP algorithm, only a simple hash and verify method.



Kinda, yeah. I think in a distributed network, using larger blocks than 4KB (say 32KB) would be much better. I had envisioned each store request supposed to be less than 1MB in size, so with a 1024-bit modulus that would require 4096 bytes of extra storage. Increasing the message size to 128KB means only 1Kb extra storage. Unfortunately, that's data that has go to go into the blockchain. It'd be nice if there was a better way that allowed for smaller storage + infinite challenges.Are my numbers right, here?Definitely, the best way would be to develop this in steps, and the first step would definitely not implement the E-PDP algorithm, only a simple hash and verify method.

Sarchar



Offline



Activity: 88

Merit: 10







MemberActivity: 88Merit: 10 Re: [ANNOUNCE] Whitepaper for Bitstorage - a peer to peer, cloud storage network November 29, 2013, 05:38:47 AM #19 Quote from: mappum on November 27, 2013, 08:47:32 PM It all looks pretty solid, I've only come up with a few small issues.



First of all, I don't think there is a need to limit the downloads to nodes that are close and the owner. This prevents use as a CDN, and also, it is trivial to keep generating new private keys until one is found that is close to the desired file.



Right, ultimately however, each storage node should get to decide for himself which nodes to allow the transfer to. I don't think it is trivial, actually. If I have a key that's only a few bits away, it's going to be very hard for you to search for a key closer. With large amounts of data and keys, it's extremely likely that someone else will be between you and data randomly.



Quote Also, (this may or may not be a problem) as mentioned in IRC, attackers could also keep changing their data to change its hash to decide what nodes they want to store it.

I see this as a benefit, actually: store the same data twice but with two different hashes. You could change the encryption key and/or a nonce in the header. In fact, this might help distribute your data more effectively.



Quote A bigger problem is that infinite nodes can be hosting the same data while the owner will only pay out to n nodes. The nodes that get to be paid are simply the ones who announce it first, and any attacker can just keep announcing the data they have (unless all nodes are recording all announcements). This could add up to be a lot of data. Even with no attackers, it means potential income isn't guaranteed, and you will lose a lot of it from the bad luck of not being first.



It's not supposed to be first-come-first-serve, but it's supposed to be more like closest-first-comers. It means that if you later join and you're closer than someone else, you can claim the payment if miners decide to throw you in.

Right, ultimately however, each storage node should get to decide for himself which nodes to allow the transfer to. I don't think it is trivial, actually. If I have a key that's only a few bits away, it's going to be very hard for you to search for a key closer. With large amounts of data and keys, it's extremely likely that someone else will be between you and data randomly.I see this as a benefit, actually: store the same data twice but with two different hashes. You could change the encryption key and/or a nonce in the header. In fact, this might help distribute your data more effectively.It's not supposed to be first-come-first-serve, but it's supposed to be more like closest-first-comers. It means that if you later join and you're closer than someone else, you can claim the payment if miners decide to throw you in.