Topic: [ANNOUNCE] Whitepaper for Bitstorage - a peer to peer, cloud storage network - page 2. (Read 9047 times)

As far as I can tell, Tahoe-LAFS doesn't offer any incentive for me to contribute my storage and bandwidth to the network.

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, 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.


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

Please look up Tahoe-LAFS, and how it can be used with I2P! Tahoe-LAFS is developed by experienced computer scientists and cryptography experts. I2P is an anonymization network. The combination is a far more flexible and advanced decentralized storage system than Freenet, and is under active development with flexible access control features.

https://www.i2p2.de and https://tahoe-lafs.org

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.

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?

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.

Bitstorage - 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.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-----