Storage BIP

cgilliard commented at 5:18 pm on April 20, 2021: contributor

decentralized storage bip 3476985a17

update storage bip c9b34a88b9

fix path c9104d900c

Update bip-XXXX.mediawiki 7b240fcbd2

Update bip-XXXX.mediawiki e962fab418

luke-jr added the label New BIP on Apr 25, 2021

gmaxwell commented at 9:34 pm on April 25, 2021: contributor

I don’t really see the connection with Bitcoin.

in bip-XXXX.mediawiki:20 in e962fab418

15+
16+This BIP describes a layer two protocol for storage of data using Bitcoin as the underlying cryptocurrency.  This BIP is dependent on BIP-XXXX and BIP-XXXX.
17+
18+==Motivation==
19+
20+There are several implementations of decentralized storage [<a href="#references">1</a>] [<a href="#references">2</a>] [<a href="#references">3</a>], we propose one that ties into the other services being described and uses Bitcoin as the base currency. A truly decentralized and private storage mechanism would have many uses and would eliminate trusted providers and replace them with commoditized storage providers. Many other applications could be built upon this decentralized storage layer as well.

harding commented at 10:00 pm on April 25, 2021:

I think the three links here would be preferable as using mediawiki reference style, e.g.:

[...] decentralized storage<ref name="storj">https://www.storj.io/</ref><ref name="filecoin">https://filecoin.io/</ref><ref name="sia">https://sia.tech/</ref>

in bip-XXXX.mediawiki:26 in e962fab418

21+
22+==Specification==
23+
24+===General===
25+
26+The decentralized storage proposed would use lightning network, tor and work in a manner similar to how Bittorrent [<a href="#references">4</a>] works except that individual pieces of the file may be downloaded in order to enable streaming. Each piece of content, whether text, image, audio, or video can be thought of as either a document or a series of documents. Each document will be a maximum of 2,560 kb. For larger files, multiple documents may be linked to one another. Video files may use multiple "look ahead" links for buffering purposes.

harding commented at 10:01 pm on April 25, 2021:

Nit: odd that “Bittorrent” is uppercased but “lightning network” and “tor” are lowercased.

harding commented at 10:04 pm on April 25, 2021:

Technical nitpick: it would be nice to provide a reason for why documents are a maximum of 2.5 MB + header and maybe a reference for why that particular magic number was chosen.

in bip-XXXX.mediawiki:82 in e962fab418

77+
78+===Hosting files===
79+
80+Based on the described protocol, some users may choose to download files and let others download from them for a profit. Such users, will notify the trackers after they have downloaded the files that they are available for download from them and the price. These users may make a profit by hosting files.
81+
82+===Proof of Burn===

harding commented at 10:51 pm on April 25, 2021:

Technical comment: generically what you’re proposing is usually called fidelity bonds, which may be accomplished using alternatives to proof of burn (e.g. UTXO ownership proofs or timelock proofs).

in bip-XXXX.mediawiki:42 in e962fab418

37+
38+<img src="bip-XXXX/decentralized_storage_diagram.png">
39+
40+===Publishers===
41+
42+Each document will be seeded by the publisher. Everyone on the network has a TOR v3 onion address. The seeder who creates the document, will sign the document with their private key corresponding to their onion address. If the document is a single document (as opposed to a chain of documents for videos and other large files), the format will be as follows:

harding commented at 0:54 am on April 26, 2021:

Last I checked—which was years ago—the Tor project asked people not to use them for torrenting. Although Bitcoin projects aren’t required to adhere to the rules of other projects, I think it’s something we should try to do whenever we can (especially if it makes sense to do so).

in bip-XXXX.mediawiki:16 in e962fab418

11+  License: BSD-2-Clause
12+</pre>
13+
14+==Abstract==
15+
16+This BIP describes a layer two protocol for storage of data using Bitcoin as the underlying cryptocurrency.  This BIP is dependent on BIP-XXXX and BIP-XXXX.

harding commented at 0:55 am on April 26, 2021:

I don’t see how this is dependent on your other BIPs. I don’t see any other references to them in this document.

harding commented at 1:01 am on April 26, 2021: contributor

Mentioned on the mailing list https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018823.html
Date mentioned 20 April 2021
No serious criticism found as of this review

The document appears to be well formatted and consistent with the formatting guidelines of BIP2. I don’t see any fundamental reason not to offer it a BIP number.

That said, in my personal opinion, it doesn’t feel very BIP worthy to me. It’s only use of Bitcoin is via existing invoice standards (e.g. BOLT11 invoices). What it standardizes are the non-Bitcoin parts of the protocol, such as max file size, tracker apportionment, file serialization, etc. While it may make sense to specify those in a BIP for a proposal that heavily integrates with other parts of Bitcoin, I don’t think it makes sense when all the protocol does is create, relay, and pay bog-standard LN invoices.

It also isn’t clear to me that there’s currently demand for multiple applications to use this specification, and without client diversity, we don’t need interoperability specifications. I would encourage the author to work a bit more on implementation and see if any problems arise that do require special interaction with Bitcoin, e.g. preventing trackers from prefering publishers whose nodes require routing through the tracker’s own nodes.

cgilliard closed this on Apr 26, 2021

Storage BIP #1107