Editing Atomic cloud storage (section)

= Footnotes &amp; references =

* [0] http://storj.io/
* [1] http://sia.tech/
* [2] http://storj.io/storj.pdf
* [3] https://en.wikipedia.org/wiki/Erasure_code
* [4] I believe that zero-knowledge SHA 256 proofs in the context of Bitcoin can be used to accomplish Satoshi’s original purpose of OP_CODESEPERATOR. Details of the discussion can be found here.
* [5] It’s now also possible to do almost all Ethereum-based contracts on top of Bitcoin using ZK-proofs. In the future, this is only going to improve with the introduction of segregated witnesses and practical indistinguishability obfuscation lurking over the horizon.
* [6] https://github.com/CodeShark/bips/blob/segwit/bip-codeshark-jl2012-segwit.mediawiki
* [7] https://bitcoincore.org/en/2015/12/23/capacity-increases-faq/
* [8] https://en.wikipedia.org/wiki/ElGamal_encryption
* [9] This is similar to atomic cross chain transfers
* [10] To support multiple downloads of the same ciphertext, the ciphertext that the farmer is storing needs to be decrypted at the end of every download and encrypted with the next key in line.
* [11] The contract can be done now if you’re ok with TX malleability.
* [12] https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-November/000344.html
* [13] http://www.nilsschneider.net/2013/01/28/recovering-bitcoin-private-keys.html
* [14] Cracking this would require brute forcing the remaining random 64 bytes of the signatures.
* [15] The proving / verification pair can be made general-purpose so it only has to be generated once. Then it could be distributed with the software (it’s a few hundred megabytes – less if you compress it.) This would save a lot of computations.
* [16] To install Snarkfront - I recommend installing Debian 8.3. This distribution of Debian comes with version 4.9 of the gcc compiler which is needed to install Snarkfront. I couldn’t get this working on any other version of Debian (and a few versions of Ubuntu) so its quite a pain. I may upload a VirtualBox image in the future if I get time. Special thanks to Anthony Towns and Greg Maxwell for helping me with this.
* [17] https://github.com/jancarlsson/snarkfront/blob/master/test_sha.cpp
* [18] Obviously anyone can mutate TX2 which is why this scheme needs to use segregated witnesses
* [19] https://bitcointalk.org/index.php?topic=196378.0
* [20] Since it’s a “smart contract.”
* [21] https://en.bitcoin.it/wiki/Script
* [22] A more simple approach is to use micro-payment channels but the game-theory for that isn’t as favourable.
* [23] This process could also be improved a lot to make it more atomic so that valid signatures for the transactions get released to both sides at the same time. I haven’t thought of the solution for this yet. Just a basic scheme so far.
* [24] There’s an excellent discussion on the game theory dynamics for possible solutions to these problems between the Sia and Storj founders: https://forum.sia.tech/topic/21/sia-vs-storj-vs-maidsaef
* [25] I suppose you could argue that if the farmer didn’t agree to this outcome then its a type of DoS attack on the farmer - the renter claims they will pay for a certain number of downloads and then doesn’t use them which ties up hard drive space that could have been leased out to other renters who would execute their downloads. But I think the proof-of-stake section can be a solution to that problem too.