BitcoinFiles enables robust file storage on chain

Getting your Trinity Audio player ready...

BitcoinFiles is one of the multiple simple file storage platforms for Bitcoin SV. What differs from Bico.media, BitFS and others is a nice user interface to upload and share links that keep track of files uploaded in the past.

With share links, users can have their own private virtual folders on-chain. Files can be added via the site directly or via the BitcoinFiles-SDK / API by referencing your share value.

From the share folders, users can easily reference files via a URL with the transaction ID on Twetch and retrotwetch with the potential to profit off of the uploaded content. Upon upload, two transactions are generated, one is to fund the upload (and where BitcoinFiles takes a small revenue cut) and another to upload the file data in an OP_RETURN output.

The service allows file uploads up to 10MB which one may question how that is possible given the recent record 6MB file upload by @libitx.

I just used the Merchant API to push this image on chain. Almost 6mb in one push data. I think Taal took it. A few weeks ago when I took the pic, none of the miners would take it. Progress 👏https://t.co/JzmjhV32zf

— Libs (@libitx) June 1, 2020

BitcoinFiles has an API appropriately named ‘Treasure Chest’ for transaction processors to pick at for lucrative fees. This API returns transactions held with size greater than 100KB, pushing processors to up their limits and compete on fees further. BitcoinFiles will store this data internally while still letting users reference the hash of larger files, even though it may have not yet been propagated across the network.

Related to fees I recently uploaded a gif onto Twetch which cost around 9 cents to upload. Yet, I earned 27 cents from its engagement, a profit ratio of 200%.

While fees are still priced in satoshis per byte, the cost could still be too high to justify uploading larger files. This begs the question—why would a user do it in the first place? A simple answer is only if they can get more value downstream from the file upload than its cost.

This logic is why I am not too concerned about the latest debates around pruning, as this issue will be settled by economics. The same logic applies to miners and pruning, if miners can earn from serving the data then they will not prune that data. Additionally, the cost to prune 1KB of data may be greater than simply preserving it.

Another question arises—why are users paying for data uploads per byte if miners can just prune? This is nonsensical. Steve Shadders, CTO of nChain has referenced this in the past, and TAAL have implemented a simple version of this where they price 250 sats/kilobyte of OP_RETURN data instead of 500 sats/kilobyte.

Interestingly, Mark Wilcox recently pointed out that fees should be negative:

This idea may appear absurd in the context of the recent debates, but the point is that miners would bear the cost instead of users to keep valuable data in order to promote an ecosystem to develop around it.

This is what BitcoinFiles is—they are not a transaction processor, yet they provide a service, development tools and APIs that other applications can leverage. While the tiny cuts they take do not justify their storage costs at this time, one could envision that laying this groundwork paves the way for robust applications to emerge in the future.

This concept is only possible because many businesses are building on top of the same ledger, thus benefit from each other. If Business A develops tools that Business B needed, Business B now saves on time, resources, and risk by leveraging what Business A produced. This effect can be multiplicative across the space, paving the way for robust applications that can be built more quickly and efficiently than ever before.