_unwriter’s tools explained, practical use cases reviewed

Getting your Trinity Audio player ready...

The post originally appeared on Yours.org and we republished with permission from its author, Joshua Henslee.

_unwriter has been going HAM since the beginning of the New Year, releasing a new tool to enable folks to build on top of Bitcoin SV seemingly every day.

While most people paying attention can clearly see that he is contributing and is paving the way for great things to be built, perhaps some with a limited technical background are having trouble keeping up. I am fairly technical myself and I am having a hard time keeping up!

On occasion I find myself still having to go back an re-read how this stuff works, so I decided to write a post explaining what all these tools are at a high-level and some practical use cases that some have already proposed and some that perhaps no one else has thought of yet.

BitDB – BitDB is a database that structures the transactions in the blockchain in a readable, formatted way. We no longer have to write redundant code to fetch data from a transaction. This tool was released before the fork, but one must understand what this is in order to grasp how the other tools work.

Genesis, Babel, Chronos and Meta

While these seem mysterious and complex with their cryptic names, each one of these is simply a subset implementation of a BitDB.

Genesis – an BSV exclusive BitDB. It only uses the legacy address format and is optimized for performance based on the previous stress tests.

Babel – another subset of BitDB, is a database optimized for users to query arbitrary data written in OP_RETURN to the chain. Since it’s focus is only on the arbitrary data stored in the chain, therefore less, querying it will be much faster.

Use case: Babel should be used for applications that only need access to the data, files or protocols stored in the blockchain, not necessarily the scripts or other details of a transaction.

Chronos – another subset of BitDB, this database is used to track timestamps of transactions, with the caveat that this database only tracks those transactions over the previous, rolling 24-hour period.

This means that transactions sent two days ago are not in the Chronos database. Why?

If we think of Babel, we know that since the database contains less data querying it is much faster. Chronos should be very fast as well since only transactions are stored from the previous 24 hours!

Use case: Since Chronos stores each transaction with a timestamp chronologically, this database can be used as a single source of truth in terms of keeping track of timing of transactions. Users do not have to rely on inconsistencies from other nodes, their node or miners. Therefore developers have an incentive to use Chronos for their applications rather than (god forbid) their own ‘full node’.

Meta – Yet another subset of BitDB, this database contains only block attributes, ex. Block height, difficulty, timestamps, etc. all the way back to the first block mined. Since this one stores even less data than Babel and Chronos, it is the fastest BitDB instance.

Use cases:

– Leverage the Difficulty field of the block metadata to add AI features to your video game application, for example the Difficulty of the Bitcoin SV network rising would actually increase the difficulty of your video game!
– Use the timing of the next block mined or block height to determine an increase of attributes of video game character, or age of some digital character (credit to @itisbitcoin).

Now we can explore how the tools interact with each other.

Bitsocket – This tool was also released prior to the fork, it is a mechanism for listening for different types of transactions based on your own custom query, then doing some function that you implement in code.

Which other tools does it use?

This tool is used along with BitDB, meaning it can be used with each of Genesis, Babel, Chronos, and Meta.

Use cases:

– Listen to a single one of your Bitcoin addresses, (ex. the next Bitcoin address dynamically leveraging Handcash) and once a transaction is received, send an email to yourself.
– When customer pays to a Bitcoin address, but still in an unconfirmed state, send an order confirmation email to the customer. Once that transaction has a certain number of confirmations (ex. 6) send another notification to your ERP system or yourself indicating the order is eligible to be picked/shipped.

Bitpipe – Server side application that can take Bitcoin transactions requests formatted in JSON, then broadcast them to the network. This tool is probably my favorite.

The JSON tells Bitpipe how to send the transaction, meaning that the request is only a request, not a Bitcoin transaction. The owner of the Bitpipe pays for the transactions, meaning the transactions initiated in the requests are free to that party.

The request can tell Bitpipe to send 2000 satoshis to address B, or to send some encrypted data to address C – or do both in one request.

Custom filtering can be added to your instance of Bitpipe such that you only broadcast certain transactions, meaning if someone sends a random request structured in a way you do not expect, you can simply reject or ignore it.

Personally I am excited about this as it no longer requires developers to write the redundant input/output managing and transaction signing logic in their applications in order to send Bitcoin.

Any application, any programming language is trivially capable of making HTTP requests in a JSON format, enabling almost any external app to quickly interact with the Bitcoin SV blockchain.

With this, we have a method of external applications being capable of interacting with Bitcoin, without actually needing to own Bitcoin.

Don't ask companies "use the blockchain" or "just use Bitcoin"

Give them ready made products that are no different to their current tools. People won't start learning what the hell is an OP_RETURN or what's a satoshi.

Ready made. Running on BSV.

— Alex Agut (@apagut) January 31, 2019

This tool enables exactly what Alex is talking about in his tweet, we can on-board companies by just telling them to use a standard HTTP requests to a Bitpipe node with a specified JSON document/protocol in order to leverage the powerful properties of Bitcoin.

Use cases:

– Make deal with external application entity to process an X number of a certain type of transactions per month through your Bitpipe node. For example, the 3rd party can pay you $100/month in fiat, while you broadcast their transactions for a fraction of the cost and taking the profit.
– EDI transmision, an ERP system sends an HTTP request with details of 850 purchase order in OP_RETURN to a Bitpipe instance, which broadcasts the transaction to the receiver’s address. ERP does not have to manage private keys or keep track of Bitcoin.

Bitchat – This tool is more simple, it is a real-time chat application on the blockchain. Users send chat message and since it leverages Bitpipe, the transactions are free as long as it is funded.

Which other tools does it use?

BitDB, BitSocket, BitPipe

Bitcom – Bitcom is a tool you can use to create your own space, protocol or database in the blockchain. The idea is that a Bitcoin receive address generated from your private key represents uniqueness, and since it is derived from your key it proves ownership.

Using OP_RETURN, you would send a transaction containing:

OP_RETURN <yourBitcoinAddress> <your data or protocol>

Use cases:

– Leverage encryption to store your own database on-chain, where lookups are easily filterable (on your address), eliminating the need (thus reducing costs) to run a MongoDB or SQL instance for your application
– Create your own video game protocol, where commands are prefixed with your Bitcoin address, and the commands represent some state change of their character in the environment of the game

B: Protocol created by _unwriter to store and reference arbitrary data on the Bitcoin blockchain.

Which other tools does it use?

Bitcom

Use case:

– This is so bad-ass it speaks for itself.
– Create a directory of ownership of files, pictures or audio that can be referenced in your application. For example, assign files that could represent a character or set of attributes (RPG?!) to a user based on their own generated Bitcoin address.

OP_Return <yourInputAddress> <usersBitcoinAddress> <JSONDocumentAttributes>

Datapay – Leverages the bsv javascript library maintained by Ryan X. Charles, this is a library that lets you broadcast a transaction with minimal code written. You can send Bitcoin, write data or both with ease. Great place to start here for beginners looking to get into Bitcoin development.

ButtonPage – Web page where users can generate a dynamic money button on the fly, and can share the URL with others. Using the moneybutton documentation, users can easily tinker with the fields to create a custom money button that pays themselves, their friends or multiple people with any amount of Bitcoin.

This URL can also be generated in code, so that an application could generate a money button, then share with a user interacting with their application.

Use case – On an e-commerce site, generate a money button URL where users can pay the invoice (order number in OP_RETURN) for their order of goods online. This money button could be configured with multiple outputs such that the merchant and suppliers are paid at the moment the user swipes to pay for their order.

The possibilities of development on Bitcoin SV are so great with the creation of these tools and are a demonstration of what can be done with a locked down protocol.

By creating these tools, _unwriter is signaling to all of us his intent to build. He/She/They are putting pressure on us all of us by taking away the excuse to build by providing these tools that streamline development, enable scalable applications, and create the robust eco-system needed to sustain the network and security model going forward.

Let me know what you think, what can be improved in this article and what other use cases you can think of that are possible with these tools!

The original post can be found here.